Retrouvez cet article en vidéo
Retrouvez cet article en podcast
Science Reproductible
Durant cette année 2020, la crise du Covid a conduit à une production faramineuse d’articles scientifiques sur une thématique précise. Ces articles, lorsqu’ils ont été publiés dans des revues à comité de relecture, ont subi un processus éditorial accéléré. Quand, dans le temps classique de la recherche, un article peut mettre jusqu’à 2 ans avant d’être publié, les délais étaient durant cette crise raccourcis à quelques semaines au plus. Et pour cause, l’état des connaissances évoluant tellement vite durant cette crise, il était courant qu’un article ne soit plus novateur quelques semaines seulement après sa publication ou sa soumission. Par exemple, dans le processus de soumission de notre méta-analyse sur l’hydroxychloroquine, nous avons dû rajouter des articles parus entre la soumission de l’article et son acceptation finale. Et là encore, entre le moment où l’article a été accepté et le moment où il a été publié, d’autres études ont été publiées, que nous n’avons pu intégrer. Un article n’est jamais qu’une photographie des connaissances à un instant précis, dans des conditions précises.
Ce que cette production folle d’articles a mis en lumière, c’est la grande hétérogénéité des articles publiés. La publication de ces productions va du preprint médiocre, voire mauvais, aux articles publiés dans des revues prestigieuses, dont la crédibilité est bien meilleure. On a même vu durant cette pandémie des “articles” êtres publiés sous forme de document word déposé dans une dropbox, ou mis à disposition sur researchgate (un réseau social de chercheurs). Il va sans dire qu’un article déposé uniquement sur Researchgate ne devrait pas se voir accorder davantage de crédibilité que la vidéo complotiste partagé par Mme Michu sur facebook.
Pour tous ces articles, il est nécessaire d’en évaluer la qualité et la fiabilité. En effet, être publié dans une grande revue ne garantit pas le caractère irréprochable des résultats présentés. C’est ce que l’on a encore vu récemment avec le désormais fameux LancetGate où, malgré des analyses statistiques correctes, les données étaient complètement frauduleuses. Ce qui a permis de déceler la fraude, c’est le processus d’open peer review qui a fait que des centaines d’yeux et de cerveaux ont conjointement analysé ce papier pour y déceler les failles. Ici, les données étaient inventées. Cette fraude a pu être mise en lumière car les auteurs n’ont pas pu fournir à la communauté scientifique les données utilisées pour produire l’article. Il était donc impossible pour la communauté scientifique de reproduire les résultats présentés dans l’article.
L’évaluation de la qualité d’un travail de recherche est donc contrainte par sa reproductibilité. Cette reproductibilité est elle-même tributaire de plusieurs choses :
- La précision du protocole expérimental
- La disponibilité des données
- La disponibilité des algorithmes utilisés.
Concernant la précision du protocole expérimental et la disponibilité des données, le cadre qui prévôt est bien sûr le cadre légal. Je pense par exemple aux données de santé qui doivent être anonymisées et ne pas pouvoir permettre de retrouver un patient, afin de garantir le secret médical. Cela est important si, par exemple, votre jeu de données contient un patient avec une pathologie précise dans un hôpital précis. Il devient alors aisé d’identifier ce patient, même si son nom n’apparaît nulle part. Néanmoins, des méthodes d’anonymisation complète permettant de garantir la confidentialité des données même si elles sont publiques existent, comme la confidentialité différentielle. Dans les grandes lignes, cette technique consiste à rajouter dans le jeu de données original des données synthétiques qui n’ont pas d’incidence sur les analyses effectuées sur ce jeu de données. Ainsi, il est impossible de savoir si chaque donnée individuelle est réelle ou non et correspond à une personne réelle. C’est une technologie qui est déjà utilisée dans beaucoup de domaines, mais pas voire peu dans la recherche. Par exemple, Google utilise cette méthode pour faire remonter des données anonymes de ses utilisateurs. En ajoutant du bruit artificiel aux données, Google peut tracer par exemple la fréquentation des magasins, sans pour autant tracer les utilisateurs de façon individuelle pour ces statistiques.
Disponibilité des algorithmes et logiciels
Pour les algorithmes, c’est plus compliqué. Rendre un algorithme disponible peut signifier au choix :
- mettre le pseudo code à disposition, c’est à dire la mécanique interne
- mettre l’implémentation de l’algorithme à disposition, c’est-à-dire le programme permettant d’exécuter l’algorithme.
Souvent, mettre le pseudo-code où les équations décrivant un algorithme ne garantit pas une recherche reproductible, car dans un champ de recherche précis, bien peu de personnes ont les capacités informatiques nécessaires à l’implémentation de l’algorithme, à son codage. Par exemple, dans mon domaine, la biologie, la grande majorité des chercheurs sont capables d’utiliser un algorithme d’alignement de séquences (qui sert à comparer des séquences ADN) et d’en comprendre les résultats de manière fine. Mais très peu sont capables de comprendre les algorithmes eux-mêmes de manière suffisamment poussée pour les coder. Et quand bien même, très peu de biologistes ont des compétences en programmation informatique pour recoder un algorithme de novo.
Ce qu’il faut prendre en considération également, c’est que l’implémentation des algorithmes répond à des contraintes informatiques de plus en plus fortes. En bioinformatique par exemple, il ne s’agit pas seulement de faire en sorte que l’algorithme fonctionne, mais aussi et surtout qu’il fonctionne sur de grands jeux de données, de manière rapide, et parfois sur de super-calculateurs. Cela demande des compétences en programmation très subtiles, et hors du cursus du bioinformaticien moyen.
Pour pouvoir reproduire des résultats de recherche, il faut donc idéalement disposer de l’implémentation logicielle de l’algorithme utilisé. C’est-à-dire qu’il faut avoir à disposition le programme qui permette l’exécution de l’algorithme en question. A ce stade, on peut donc légitimement considérer que disposer du protocole, des données, des algorithmes et des logiciels suffit à garantir la reproductibilité d’une recherche.l n’en n’est rien Pourquoi ? parce qu’un logiciel est essentiellement une boîte noire qui convertit des entrées (données, saisie clavier, etc) en sorties (graphiques, statistiques, images, etc). Sans avoir accès au fonctionnement interne d’un logiciel, il est impossible de vérifier son fonctionnement.
Or, la possibilité d’étudier le fonctionnement interne d’un programme est garante de plusieurs choses cruciales en recherche :
- comprendre le fonctionnement, et apprendre à créer de tels programmes
- valider le bon fonctionnement et les éventuelles erreurs du programme
- améliorer le programme en lui ajoutant des fonctionnalités sans repartir à zéro
- intégrer des morceaux du programme étudié dans un programme plus large regroupant plusieurs fonctions.
Logiciels libres
Ces possibilités, ces libertés de compréhension et d’amélioration d’un programme, sont au cœur de la GNU GPL, une licence créée par Richard Stallman, qui définit légalement ce qu’est un logiciel libre.
Pour la petite histoire, l’aventure de la création du logiciel libre par Richard Stallman est due à une imprimante capricieuse. En 1980, alors qu’il âgé de 27 ans, Richard Stallman travaille au MIT où une nouvelle imprimante leur a été offerte par Xerox. Cette imprimante est sujette au bourrage papier, qui bloque les files d’impression. Pour corriger ce défaut, Richard Stallman a pour projet de modifier le pilote de l’imprimante, c’est-à-dire le logiciel qui permet à l’ordinateur de piloter l’imprimante. Il s’aperçoit que le code source du pilote n’est pas disponible, et que Xerox refuse de le communiquer. A l’époque, la communauté de programmeurs était très restreinte, et il régnait un esprit de partage. Les codes étaient empruntés, copiés, échangés, de façon libre et communautaire. Xerox, en refusant de communiquer le code source du pilote de l’imprimante, inaugurait l’ère des licences commerciales d’utilisation, c’est-à-dire la possibilité d’utiliser un logiciel sous contrainte commerciale (ici l’achat d’une imprimante) sans pouvoir avoir accès au code source. Dès lors, Stallman, révolté, jura de ne jamais confisquer l’accès au code de ses programmes, jugeant la pratique non éthique et contraire aux valeurs morales des programmeurs de l’époque.
Dans les années 80, Stallman entreprend de créer un système d’exploitation alternatif à Unix, qui était très en vogue à l’époque, pour permettre à chacun de l’installer librement et gratuitement sur son ordinateur. A cette période, Unix coûtait plusieurs milliers de dollars. Stallman entreprend donc de concevoir le système d’exploitation libre GNU. GNU est d’ailleurs un acronyme récursif signifiant “GNU’s not Unix”. GNU en tant que système d’exploitation n’est pas un projet totalement abouti, notamment à cause de l’écriture du code du noyau, Hurd, qui patine. Néanmoins, GNU fonctionne très bien avec un autre noyau … Linux. En fait, les systèmes d’exploitation Linux sont véritablement des systèmes GNU/Linux, c’est-à-dire des logiciels GNU articulés autour d’un noyau Linux.
Quand il finalise son premier logiciel à destination du projet GNU, Emacs (un traitement de texte), Richard Stallman réfléchit à comment le protéger. S’il fournit le code tel quel, il n’empêche personne de recopier le programme, de le modifier légèrement, et de protéger l’accès au code source grâce aux nouvelles lois sur le copyright. Stallman cherche donc à créer une licence d’utilisation qui s’hérite avec le code, en ce sens qu’une personne qui utilise le code source du logiciel sous cette licence doit redistribuer le code modifié sous cette même licence. Il invente ainsi la licence GNU GPL qui définit 4 libertés fondamentales :
- Liberté 0. La liberté d’exécuter le logiciel, pour n’importe quel usage ;
- Liberté 1. La liberté d’étudier le fonctionnement d’un programme et de l’adapter à ses besoins, ce qui passe par l’accès aux codes sources ;
- Liberté 2. La liberté de redistribuer des copies ;
- Liberté 3. L’obligation de faire bénéficier la communauté des versions modifiées.
Si l’histoire complète de la création des logiciels libres vous intéresse, je vous encourage à lire la biographie de Richard Stallman, disponible en pdf.
Les logiciels libres et la recherche
Si la philosophie des logiciels libres est facilement compréhensible, elle pose plusieurs problèmes d’ordre pratique aux chercheurs qui souhaiteraient utiliser la GNU-GPL pour les projets qu’ils développent. Notamment, au début des années 2000, de nombreux logiciels de recherche ont été développés et distribués de façon non libre.
Un exemple typique que j’ai en tête est le logiciel USEARCH. USEARCH est un logiciel d’alignement et de clustering de séquences ADN très utilisé en bioinformatique. Il est gratuit d’utilisation dans sa version 32 bits, mais nécessite une licence pour sa version 64 bits. La licence pour la version 64 bits coûte 1500 dollars, ce qui la rend inaccessible pour les universités des pays en développement. A l’heure actuelle, avec l’avènement des techniques de séquençage massif, il est presque impossible de conduire une analyse bioinformatique de pointe avec la version 32 bits, qui est limitée à l’utilisation de 4GB de RAM. De plus, bien que cette version soit gratuite d’utilisation, son code source n’est pas disponible, et il est donc impossible d’en étudier finement le fonctionnement.
On peut comprendre la réticence des chercheurs et des programmeurs à rendre disponible les logiciels qu’ils développent sous licence libre. Par exemple, le fait qu’un logiciel soit utilisable et modifiable librement prétérite une potentielle rentrée d’argent. C’est une inquiétude totalement légitime, mais la licence libre n’empêche pas la commercialisation d’un logiciel. Notamment, un business modèle largement utilisé avec la licence GPL est de fournir le logiciel librement mais de vendre l’assistance et la garantie. C’est le cas par exemple de la distribution Linux RedHat. Il est également possible de vendre l’accès à un service, par exemple par l’intermédiaire d’un site web, tout en partageant les sources du projet. Par exemple, imaginons que je développe un programme qui me permette de faire de l’analyse de texte de façon très détaillée. Ce programme fonctionne en ligne de commande et son fonctionnement est peu aisé. Je peux très bien développer un site web payant via lequel les utilisateurs peuvent utiliser mon logiciel de façon simple, tout en distribuant le code source de mon logiciel. Ce qui est facturé n’est pas le logiciel, mais sa facilité d’utilisation. De plus, il existe d’autres types de licence libres que la GNU GPL, qui permettent une plus grande souplesse dans l’utilisation commerciale du logiciel développé.
Distribution égalitaire et évolutive
Le fait, pour un logiciel de recherche, d’être non-libre, ou privateur (au sens où il prive l’utilisateur des quatres libertés fondamentales décrites plus haut), le rend très vite limité. Dans le cas de USEARCH, la conséquence a été la création d’un projet parallèle, VSEARCH, visant à reproduire et étendre USEARCH, sous licence libre. La description du logiciel, sur Github, stipule :
Le but de ce projet est de créer une alternative à USEARCH développé par Robert C Edgar (2010). Ce nouvel outil devrait :
- être open source, avec une licence libre adéquate
- être gratuite d’utilisation
- avoir un design 64 bits qui peut gérer de très grandes bases de données et bien davantage que 4GB de RAM
- être aussi précis ou plus précis que USEARCH
- être aussi rapide ou plus rapide que USEARCH
Ces prérequis ont été atteints très tôt dans le projet, et les fonctionnalités de VSEARCH ont été étendues. Comme le projet est open source, de nombreux bugs ont pu être mis en lumière et corrigés par des utilisateurs. De plus, ayant le code source à disposition, d’autres programmeurs ont rendu VSEARCH disponible de façon native pour différentes plateformes et systèmes d’exploitation, rendant l’installation et l’utilisation de VSEARCH extrêmement aisé. VSEARCH est donc devenu, en 4 ans seulement, la référence dans ce type d’analyse et a supplanté USEARCH.
Le premier avantage des logiciels libres dans la recherche est donc d’avoir des logiciels utilisables par tout le monde, évolutifs, et qui bénéficient d’une communauté de développeurs virtuellement illimité, car tout le monde peut contribuer au projet en proposant des améliorations, en remontant des bugs et parfois en les corrigeant.
Résolution des discordances
Le deuxième avantage qui me vient à l’esprit est la possibilité de comprendre les différences de résultats obtenus entre deux implémentations d’un même algorithme. L’exemple le plus parlant que j’ai sous la main est l’implémentation de l’algorithme de régression LASSO, qui diffère sous R et sous python. En python, LASSO est disponible dans la librairie scikit-learn. Sous R, LASSO est disponible dans la librairie glmnet. Ces deux librairies sont sous licences libres, et leurs codes sources respectifs sont disponibles pour tout le monde. Comme les implémentations sont différentes, les résultats renvoyés par l’une ou l’autre de ces implémentations sont différents. L’analyse des sources par plusieurs utilisateurs a permis de mettre à jour cette différence d’implémentation, et de fournir une manœuvre très simple pour convertir les résultats d’une implémentation à l’autre. Mieux encore, cette manipulation est elle-même publiée en open-source.
Ré-implémentation et itération
Le troisième avantage est de permettre une ré-implémentation d’algorithmes, en se basant sur des implémentations existantes. Dans mon domaine, j’utilise un algorithme pour calculer des co-occurrences, c’est-à-dire des probabilités que deux espèces différentes se trouvent toujours au même endroit. Il existe plusieurs algorithmes pour faire cela, mais celui que j’utilise est très peu utilisé dans la communauté. Il existe une librairie R qui permet de faire tourner cet algorithme mais il est excessivement lent et plante quand le nombre d’espèces considérées est supérieur à 200. Or, dans mon cas, j’ai besoin de faire tourner cet algorithme sur environ 100 000 espèces.
En étudiant le fonctionnement de la librairie existante, j’ai pu identifier les bottlenecks, c’est-à-dire les structures ou les portions de codes qui limitent le programme. En me basant là-dessus, j’ai pu conserver les pièces qui fonctionnent et réécrire une librairie complète qui permet de faire tourner l’algorithme de façon très efficace. Notamment, mon implémentation permet de faire tourner la librairie sur un des clusters (en gros des supercalculateurs). Le fait d’avoir eu accès à la librairie existante m’a permis de ne pas devoir commencer de zéro, et d’identifier des facteurs limitant que je n’aurais probablement pas anticipés. Cette librairie n’est pas encore disponible publiquement, mais elle sera publiée sous licence GPL dès que j’aurais résolu le dernier bug.
Reproduction immédiate et vérification des erreurs
Enfin, le dernier avantage des logiciels libres dans la recherche est de permettre une reproduction immédiate des résultats. J’utilise exclusivement des logiciels libres dans ma recherche. Aussi, si je publie un article, et que je rend les données disponibles avec le code source qui m’a permis de faire l’analyse, je sais que d’autres chercheurs pourront sans aucun soucis refaire tourner l’analyse car le logiciel que j’utilise, R, est gratuit et libre, et est installable par n’importe qui. Parallèlement, mes pairs peuvent déceler d’éventuelles erreurs dans mon code et me faire parvenir un correctif.
Pendant le Covid, de nombreux chercheurs ont publié le code source de leurs modèles en même temps que les articles scientifiques dans lesquels ces modèles sont utilisés. C’est le cas de l’Institut Pasteur ou de l’Imperial College, par exemple. Ainsi, lorsque les articles sortaient, j’avais juste à télécharger le code et à l’exécuter pour reproduire les résultats obtenus dans les articles. J’ai d’ailleurs énormément appris en étudiant les codes mis à disposition, puisqu’ils utilisaient des méthodes que je ne connaissais pas. La mise à disposition du code source permet donc une reproduction immédiate, une vérification des erreurs, et un apprentissage plus rapide.
Conclusion
On l’a vu, le logiciel libre s’impose petit à petit comme un standard dans la recherche, ce qui est à mon sens une bonne chose. Le fait de permettre aux autres chercheurs d’avoir accès à nos programmes et de les modifier, de les étudier, engendre une mécanique d’évaluation et d’amélioration perpétuelle des programmes, algorithmes, etc. Ainsi, la recherche progresse plus vite. En mettant ces codes et programmes à disposition, les chercheurs permettent également à leurs pairs de reproduire les travaux existant de manière plus rapide et de construire des framework qui deviennent standard, non pas à cause de leur facilité d’utilisation ou de leur monopole commercial, mais simplement parce qu’ils sont meilleurs et que de nombreuses personnes contribuent au succès de ces frameworks.
Et en statistiques alors ? Pour les analyses statistiques, je vous recommande donc logiquement de produire vos analyses à l’aide d’un logiciel libre. Pour ma part j’utilise R. R possède une multitude de librairies qui lui permettent donc d’effectuer environ n’importe quelle analyse. Je sais également que n’importe quel chercheur dans le monde peut reproduire mon travail avec exactement les mêmes scripts. Je recommande d’éviter les logiciels comme SAS ou Graphpad qui, bien que peut-être plus simple de prime abord, ne sont pas accessibles à tous. Vous pouvez très bien utiliser d’autres logiciels ou langages libres, comme Python ou Julia, pour les plus connus. L’essentiel étant pour moi de demeurer avec des logiciels libres, à cause de toutes les qualités énumérées plus haut.
Vous l’aurez compris : pour moi, les logiciels librs sont les garants d’une recherche reproductible.
Commentaires récents