Opinions : Croquis mensuel de Pascal Francq – Septembre 2017
Pascal Francq

Des plates-formes logicielles de recherche ouvertes

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 [A]  [A] Il existe évidemment des dispositifs expérimentaux dont les coûts exorbitants rendent la multiplication impossible. C’est notamment le cas du CERN. Mais, théoriquement, si on disposait de fonds illimités, on pourrait recréer plusieurs CERN fournissant les mêmes résultats.. 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 [B]  [B] Il existe, par exemple, plusieurs méthodes numériques pour calculer une transformée de Fourier. Certains algorithmes sont très rapides mais plus approximatifs alors que pour d’autres, c’est le contraire. Bien entendu, les résultats sont souvent assez proches. Mais des petites différences qui s’accumulent aboutissent parfois à des écarts finaux non négligeables.. Même différentes mises en œuvre d’un algorithme donné se comportent parfois diversement [C]  [C] Modifier l’ordre de calculs arithmétiques sur des nombres réels introduit généralement des différences dans le résultats dues aux erreurs d’arrondis.. 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é [D]  [D] Un exemple d’astuce est l’utilisation d’heuristiques d’optimisation locale. Il s’agit d’algorithmes qui cherchent à améliorer un tout petit aspect bien particulier d’un problème. Bien qu’elles ne représentent parfois que quelques lignes dans un programme qui peut en contenir des milliers, ces heuristiques améliorent souvent la qualité des solutions produites. 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» [E]  [E] Dans le cas d’un document texte composé de mots, de phrases, de paragraphes et de chapitres, on le représente souvent par un vecteur dont les coordonnées représentent les mots qui y sont présents, et dont les poids sont pondérés par une méthode qui tient compte de leur caractère discriminant ou non.. Or quelques petits changements (pas toujours explicités) dans un prétraitement suffisent à altérer le résultat final [F]  [F] Un exemple classique en traitement de données textuelles est d’éliminer les mots vides (un, une, le, la, etc.). Même si ce prétraitement est mentionné, la composition exacte du dictionnaire de mots vides utilisé n’est jamais précisée. Or, l’ajout de quelques mots clés «bien choisis» influence le résultat du prétraitement et donc, par voie de conséquence, les résultats finaux..

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 [G]  [G] Les logiciels sont développés grâce à des langages de programmation qui permettent d’écrire les instructions qui devront être exécutées par l’ordinateur. L’ensemble des instructions d’un programme écrites dans un langage de programmation s’appelle le code source du programme. 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.
De plus, lorsqu’un logiciel propriétaire n’est plus maintenu, ce qui arrive souvent pour des logiciels de niche, les chercheurs perdent toute capacité à répliquer leurs propres expérimentations ! Alors que, lorsque l’on dispose du code source, on peut le recompiler (en l’actualisant si nécessaire).
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

J’ai procédé à une petite expérience informelle. L’algorithme k-Means est souvent une référence dans les problèmes de partitionnement de données. Une simple recherche avec le mot-clé «k-Means» dans Google Scholar renvoie à 29.200 articles publiés en 2016.
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 [H]  [H] J’ai utilisé le logiciel open source SLOCCount pour estimer l’effort de développement de ma propre implantation de l’algorithme.. 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 [I]  [I] Un effet de bord se produit lorsqu’un composant logiciel modifie inopinément des états du programme (comme la valeur de variables) qui influencent d’autres composants. 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 :
  1. Promouvoir des logiciels open source qui garantissent l’accessibilité au code source.
  2. 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).
  3. Éviter le redéveloppement inutile des mêmes logiciels pour se focaliser uniquement sur l’optimisation de ceux existants.
  4. 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 [J]  [J] On peut décomposer cette tâche en sous-tâches reprenant l’extraction des données brutes et leur transformation en données utilisables par ou plusieurs prétraitements., (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).
figs/plate-forme_de_recherche.svg
Figure 1 Une architecture multi-couches.
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.
D’autant plus que des choix de programmation pointus peuvent aboutir à du code source plus sûr et de meilleure qualité. Bjarne Stroustrup montre, par exemple, que certaines fonctionnalités très précises d’un langage de programmation évitent des bugs de conversion des unités [K]  [K] En 1999, la NASA perd la sonde Mars Climate Orbiter, qui avait coûté la bagatelle de $ 654 millions, à cause d’une erreur de navigation. Cette dernière était due à un bogue dans le logiciel embarqué relatif à la conversion des unités. [7].
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» [L]  [L] Souvent, les différents cours sont associés à des travaux pratiques indépendants focalisés sur un tout petit aspect, souvent ultra-pointu. La mise en place de projets personnels plus ambitieux, de préférence couplés à des initiatives plus importantes, apporterait une réelle plus-value aux formations actuelles.. 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 [M]  [M] L’évaluation académique ne se base pas seulement sur le nombre de publications, mais également sur la qualité accordée aux journaux dans lesquels elles sont publiées. Actuellement, seul un nombre somme toute assez restreint de revues anglo-saxonnes sont considérées comme de qualité («revues de rang A»). En pratique, publier dans une revue qui n’est pas perçue comme «bonne» ou ne rien publier du tout revient au même.» 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 [N]  [N] Loin des discours officiels d’universités «ancrées dans la Cité», les aspects d’enseignement et de service à la communauté rentrent très rarement en compte lors de l’évaluation d’un dossier académique.. 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.