Notre tribune sur la recherche reproductible dans “Le Monde”

Lors de notre visite au salon Innovatives SHS en mai dernier, nous avons longuement discuté avec Yvan Stroppa qui représentait RunMyCode. Le projet franco-américain RunMyCode est tout à fait emblématique de notre vision de la recherche, en ce qu’il propose une vision “augmentée” de la publication scientifique : et si à côté de votre article classique vous mettiez en ligne votre code et vos jeux de données, dans une interface permettant à chacun de faire tourner le code et jouer avec les données ? La discussion, à bâtons rompus, faisait écho à nos réflexions sur la recherche reproductible et nous avons fait le pari d’en tirer une tribune pour le cahier Science & médecine du Monde. L’article ayant été publié dans le journal et sur le site du Monde, nous vous offrons ci-dessous la “version auteur” augmentée de ses liens hypertexte.

MàJ octobre 2013 : Suite à un changement de stratégie, le service RunMyCode se limite désormais au dépôt de code et de data. Les fonctionnalités d’exécution du code que nous décrivons ci-dessous appartiennent désormais à Run&Share, qui poursuit cette vision de la recherche reproductible.

En avril dernier, un pavé a été jeté dans la mare de la recherche en économie : l’un des articles économiques les plus cités ces dernières années par les partisans de l’austérité, selon lequel le taux de croissance d’un pays devient négative quand sa dette dépasse 90% du PIB, serait entaché d’erreurs de calcul et de manipulations de données. Ce sont trois économistes de l’université du Massachussets qui ont découvert la fraude après avoir obtenu l’accès à la feuille de calcul Excel que les chercheurs d’Harvard Carmen Reinhart et Kenneth Rogoff avaient utilisé pour bâtir leur démonstration. En cause : des erreurs de formules Excel, une exclusion arbitraire de certaines données et une pondération non conventionnelle — sans lesquelles le résultat ne serait plus du tout probant et ne plaiderait pas en faveur d’un maintien de la dette en deçà de 90% du PIB.

Quand l’affaire a éclaté, la majorité des chercheurs en économie, et plus largement en sciences humaines et sociales, se sont sentis sans doute protégés par leur honnêteté intellectuelle et des pratiques de travail perçues comme meilleures (par exemple utiliser un langage de programmation plus traçable qu’Excel, comme Matlab ou R). Mais est-ce suffisant ? Il suffit de constater que les erreurs de code arrivent très vite (conduisant parfois au retrait d’un article erroné après sa publication) et que la majorité des chercheurs qui codent n’a pas une bonne compréhension des tests logiciels, pour répondre non. À l’inverse, une bonne pratique consistant à partager votre code rédigé dans un langage open source augmente les chances d’en déceler les erreurs et de le rendre plus robuste.

Les sciences basées sur l’informatique ont cet avantage sur les sciences expérimentales qu’elles sont facilement reproductibles : donnez à quiconque votre code source et vos données, et il retombera sur les mêmes résultats que vous. Faites-le saisir ses propres données, et tout le monde pourra s’approprier votre travail : votre code devient un outil. C’est le pari qu’a fait en 2011 RunMyCode, projet académique international à but non lucratif, initialement porté par une équipe française d’ingénieurs et de chercheurs du CNRS, d’HEC Paris et de l’Université d’Orléans. Il permet d’accompagner sa publication scientifique traditionnelle d’un « site compagnon » interactif, pour en faire une « publication exécutable » au sens informatique du terme. D’abord concentré sur des problématiques de calculs statistiques liés à l’économétrie, RunMyCode s’ouvre sur les autres disciplines scientifiques. Les 80 sites compagnons déjà créés permettent d’une part de partager un savoir faire de haut niveau, et d’autre part de le rendre interactif via une interface d’exécution du code et de saisie des données. Il apporte également une traçabilité de toutes les conditions de version et d’exécution qui ont permis d’obtenir les résultats décrits, pour en favoriser la reproduction.

RunMyCode bénéficie du soutien technologique du CNRS via la très grande infrastructure de recherche Huma-Num, de l’ANR, de la fondation HEC et de la fondation Alfred P. Sloan (New York). Il bénéficie également depuis 2012 du soutien et de la collaboration active d’une équipe de chercheurs de l’EFREI, école d’ingénieurs en informatique.

Un site compagnon permettant de reproduire vos résultats n’équivaut pas à la validation ultime que serait une réplication indépendante de vos travaux, mais celle-ci n’est pas toujours possible (par exemple quand les données sont colossales ou coûteuses à rassembler, comme dans les études de cohorte en épidémiologie ou les observations astronomiques). La recherche reproductible est un “minimum atteignable” pour évaluer la validité d’un résultat scientifique et ne pas se contenter d’une situation où un résultat est soit répliqué (donc validé indépendamment par la communauté) soit non répliqué (donc sujet à caution). Et même avec cette contrainte minimale, on s’aperçoit que les chercheurs utilisent souvent des logiciels qui ne permettent pas de retracer l’ensemble des analyses de données effectuées ; et quand ils codent (par exemple avec Matlab ou R), ils font souvent appel à différentes routines et différents processus dont le lien entre eux n’est pas sauvegardé. Une enquête récente a même montré que les chercheurs interrogés choisissent en grande majorité leurs logiciels non pas en fonction de critères strictement scientifiques, mais parce qu’ils leur ont été recommandés ou parce qu’ils les ont vu utilisés dans des publications scientifiques — quand bien même ces publications ne fournissent pas la preuve que le logiciel est fiable. Ce sont donc plusieurs décennies de pratique informatique qu’il faut refonder, en impliquant l’ensemble des développeurs de logiciels scientifiques, de leurs utilisateurs et des éditeurs de revues scientifiques, pour bâtir une “culture de la reproductibilité” à tous les échelons de la recherche.

En février dernier, Daniele Fanelli, chercheur à l’université d’Edimbourg spécialiste de l’intégrité scientifique, proposait dans la revue Nature d’élargir la définition de la fraude scientifique à toute omission ou déformation de l’information nécessaire et suffisante pour évaluer la validité et l’importance d’une recherche. Jusqu’ici, la fraude a surtout été combattue en essayant de rendre les scientifiques plus objectifs et honnêtes que le commun des mortels, ce qui a fait perdre de vue que ce ne sont pas les qualités intrinsèques des chercheurs qui rendent les connaissances scientifiques robustes, mais bien l’exercice du jugement des pairs. Donc si l’on veut faire progresser la bonne science, quoi de mieux que de renforcer sa capacité à l’auto-correction ? Fanelli propose par exemple que les revues scientifiques se dotent de chartes dictant l’ensemble des informations nécessaires et suffisantes à une “bonne” publication. Cette franchise ne ferait pas disparaître l’autonomie du chercheur : par exemple, libre à lui ou elle de “pêcher” le résultat statistiquement significatif dans ses données, à condition d’indiquer l’ensemble des tests statistiques réalisés afin que ses pairs puissent décider des risques de faux positifs. Ainsi, la lutte contre la fraude scientifique se jouerait plus sur le terrain de la communication des résultats que sur celui du comportement des chercheurs. La culture de la reproductibilité est une alliée de l’intégrité scientifique.

Anatole France écrivait en 1889, dans sa nouvelle Balthasar, que “la science est infaillible ; mais les savants se trompent toujours”. Nous engageons les chercheurs à reconnaître leurs limites et à favoriser le dialogue constructif au sein de la communauté par plus de transparence. Une voie consiste à accompagner les publications scientifiques des jeux de données et codes sources qui permettront à leurs collègues de reproduire leurs résultats. Et qui sait si en chemin ils n’y trouveront pas d’autres bénéfices, en diffusant mieux leurs résultats et en permettant à un public large de “jouer” avec le code et les données.

P.S. Nous remercions Bastien Guerry, qui a pris le temps de partager avec nous sa vision de la recherche reproductible.

22 réponses à Notre tribune sur la recherche reproductible dans “Le Monde”

  1. Pour cette tribune (et suite à une question d’Elifsu), j’ai essayé de savoir combien d’articles ont été rétractés suite à des erreurs de code.

    Je connaissais déjà B.G. Hall & S.J. Salipante, “Retraction: Measures of Clade Confidence Do Not Correlate with Accuracy of Phylogenetic Trees,” PLoS Computational Biology, vol. 3, no. 3, 2007; http://www.ploscompbiol.org/article/info:doi%2F10.1371%2Fjournal.pcbi.0030051 J’ai alors utilisé la recherche de citations dans Google Scholar pour trouver un autre cas citant celui-ci. Je découvre cet article éditorial de Science : G. Miller, “A Scientist’s Nightmare: Software Problem Leads to Five Retractions,” Science, vol. 314, no. 5807, 2006, pp. 1856–1857 . Il concerne ces rétractions : G. Chang et al., “Retraction of Pornillos et al., Science 310 (5756) 1950–1953. Retraction of Reyes and Chang, Science 308 (5724) 1028–1031. Retraction of Chang and Roth, Science 293 (5536) 1793–1800,” Science, vol. 314, no. 5807, 2006, p. 1875; http://www.sciencemag.org/cgi/content/full/314/5807/1875b

    La requête “as a result of * bug” + (retraction OR correction) ne m’a pas permis de trouver plus de références dans Google Scholar — il faudrait sans doute la raffiner. Du coup j’ai des références qui remontent à 2006-2007, et rien depuis, ce qui est étonnant quand on sait que les rétractions vont croissant.

    D’autres idées ou exemples ?

  2. Pierre Morel dit :

    Bravo pour l’article ! Une petite mention pour R et reproductibilité (probablement too much pour le lectorat du Monde): il existe des paquets comme sweave qui permettent d’intégrer du code dans son manuscrit latex. A chaque fois que le manuscrit est généré, les résultats et figures sont aussi générés à la volée en partant potentiellement des données de base. Dommage que ça ne marche pas pour les neurosciences (térabits de données, pipeline de traitement des données avec plein d’étapes, numériquement intensif et pas forcément automatisé –spike sorting). Sans parler de la préciosité des données: des enregistrements électrophysiologiques chez le singe représentent des années de travail (avec des subtilités de tâches qui échapperaient à un oeil extérieur), et on peut souvent les ré-analyser avec de nouvelles techniques plusieurs années après la publication du premier papier… du coup c’est plus open-collaboration que open-access. Et pour l’ouverture de données, certains s’y mettent aussi, ici une plateforme adaptée à nos types de données G-node: http://www.cognition.tu-berlin.de/fileadmin/fg7/people/tiziano/HerMeiNawSchiZit2008.pdf

    • Merci ! Je connais un peu Sweave et j’en parle lors de mes interventions dans les labos. A défaut, si tes données sont en HDF5, peut-etre que les réflexions de Konrad Hinsen peuvent t’intéresser (par ex. http://dirac.cnrs-orleans.fr/~sputnik/static/pdf/1-s2.0-S1877050911001190-main.pdf ) Et sinon, ton anecdote sur les données me rappelle un titre que j’aime bien : “Today’s Data are Part of Tomorrow’s Research” (http://journals.sfu.ca/archivar/index.php/archivaria/article/view/13156/14406 )

      • Pierre Morel dit :

        J’avais essayé de me mettre au HDF5 pour les données de mon expé (c’est un programme maison qui tourne, donc je peux faire ce que je veux), mais j’ai abandonné face à la doc plutôt austère de l’API (le .csv reste très simple et aussi plutôt ouvert). Par contre la prochaine machine-à-enregistrer-plein-de-neurones que l’on va acheter a l’air de pouvoir exporter en HDF5, je re-jetterai un coup d’oeil !

    • Bonjour,

      En ce qui concerne les outils de mise en oeuvre de la « recherche reproductible » (qu’il serait plus approprié de désigner par « analyse reproductible des données »), mon expérience est que la combinaison de org-mode (un mode de l’éditeur emacs dont Bastien Guerry, remercié à la fin de l’article en haut de la page, est l’un des principaux développeurs) avec R ou Matlab ou Python ou Common Lisp ou … (la liste est longue et les différents langages peuvent être employés dans le même document) et beaucoup plus efficace que la combinaison de Sweave (c’est-à-dire R) avec LaTeX.
      Mon expérience est aussi que l’approche fonctionne en neurosciences ; c’est précisément dans le cadre d’analyses non entièrement automatisées qu’un outil permettant de mélanger du code et une description de ce que fait le code (ou une discussion de pourquoi une valeur précise d’un paramètre a été choisie) s’avère extrêmement important (pour qui veut rendre son analyse reproductible, bien sûr). Le G-node fonctionne bien pour déposer des données, même de gros jeux de données.
      Enfin, des agences de financement comme la NSF ou le NIH (aux États-Unis) et le Welcome Trust (en Grande-Bretagne) obligent les chercheurs qu’elles financent à donner accès aux données (ainsi qu’aux codes pour la NSF) même si ceux-ci ne semblent pas en être conscient en général. Pour une discussion de ce point, ainsi qu’un historique de la « recherche reproductible », voir (je m’excuse pour l’auto-publicité) : http://hal.archives-ouvertes.fr/hal-00591455/fr/. Les fichiers sources rendant cette article sur la « recherche reproductible » lui-même reproductible sont sur mon site : http://xtof.disque.math.cnrs.fr/#talks.

      Christophe

    • Bastien dit :

      Content de voir mentionné Sweave et la programmation littérale – on en avait parlé avec Antoine et Elifsu pendant la phase de gestation de l’article (je n’ai pas pu participer à la phase de rédaction finale).

      Je mentionne au passage cet article, expliquant comment utiliser Emacs et Org-mode pour la programmation littérale : http://www.jstatsoft.org/v46/i03/paper C’est important parce qu’il met le concept de programmation littérale à la portée de nombreux utilisateurs, il n’est plus nécessaire de connaître LaTeX et Sweave.

      • Konrad Hinsen dit :

        L’approche d’Org-mode/Babel est tout à fait intéressant et je m’en sers moi-même pour mes notes de recherche. Pourtant, je l’ai abandonné pour des projets collaboratifs parce que la plupart des mes collaborateurs n’utilisent pas Emacs. Il y en avait un qui voulait bien installer tout ce qu’il faut pour s’y mettre, mais j’ai fini par passer un temps déraisonnable à lui expliquer comment installer et configurer Emacs et Python. En fin de compte il a abandonné.

        C’est d’ailleurs cette expérience qui a lancé mes reflexions menant à ActivePapers (http://www.sciencedirect.com/science/article/pii/S1877050911001190). Si la reproductibilité exige que tout le monde adopte les mêmes logiciels ou les même langages de programmation, ça ne marchera jamais, encore moins si ces logiciels sont assez complexes. Il faut alors attaquer le problème à l’autre bout: sous quelle forme peut-on échanger et archiver les logiciels et les données pour que leurs usage se fasse avec un minimum de dépendances et en laissant la porte ouverte à un maximum d’interfaces utlisateur ?

  3. Patrick Prouzet dit :

    Votre tribune est intéressante et soulève le problème de la qualité du traitement des données, mais ne soulève qu’une partie du problème et notamment pas celui de la qualité des données elles-mêmes qui en biologie (c’est ma thématique) est très souvent dépendante de la cohérence de l’échantillonnage. C’est un vaste problème qui ne peut pas être résolu seulement par un traitement rigoureux de l’information.
    Force est de constater que ce problème repose souvent sur l’expérience de l’expérimentateur et sa capacité à pré-analyser le problème étudié.

    C’est un débat complexe, mais je vous rejoins sur le fait que nombre de publications actuelles ressemblent plus à des jeux de simulations qui devraient être éprouvés plus sérieusement qu’ils ne le sont, surtout quand ils servent de base à la gestion des ressources.

  4. François Briatte dit :

    Quand j’ai commencé à enseigner les stats, je disais, “partager son code, libérer ses données, c’est moderne, c’est encore mieux, etc.” Je présentais le matériau de réplication comme un (gros) “plus”. Maintenant, j’ai changé de technique : j’enseigne le partage du code et des données par défaut, et je présente le fait de ne PAS partager comme un (très gros) “moins”.

    Expérience intéressante : j’ai proposé aux 17 étudiants de 2e année qu’on a fait bosser sous R à Reims d’utiliser http://gist.github.com pour publier leur devoir de fin d’année. Ils l’ont presque tous fait, mais en utilisant l’option “publier en privé”.

    • Bastien dit :

      L’article dit “open source” de manière un peu floue : on ne sait pas s’il s’agit juste de transparence via la publication, ou de libération à proprement parler (autorisant la réutilisation).

      Les réflexions autour des licences pour les bases de données dans l’open data pourraient être utiles ici : alors que dans le logiciel, l’important est de pouvoir modifier et redistribuer des versions modifiées, pour les données scientifiques comme pour les données de l’open data l’important est surtout de pouvoir les *utiliser* – d’où le fait que la publication puisse suffire, à mon avis.

      Par contre, pour ce qui est du code qu’on utilise pour faire les calculs, ça me paraîtimportant de les publier pour faciliter la vérification, mais encore plus important de les libérer pour que la communauté scientifique contribue à améliorer les vérifications, à optimiser, etc.

  5. Jean-Noël dit :

    Je sais que certains programmeurs ne veulent pas placer leurs productions sous une licence Open-source pour l’unique raison que cela revient à montrer ses sous-vêtements : s’ils ne sont pas propres, c’est la honte.
    Un code mal fichu, avec des choses qui ne servent à rien, un manque de méthode, des choses qui tiennent par miracle, c’est la honte, de la même manière.
    C’est pour ça que les logiciels open-source sont aussi souvent les plus sérieusement programmés et que Linux plante moins que Windows.
    J’imagine que c’est à peu près la même question.

    • Bastien dit :

      Yes. Comme je ne suis pas développeur de formation, seulement amateur, j’ai toujours eu l’impression d’avoir 4 ans au milieu d’une cours d’adultes. Ca aide à ne pas avoir honte de ses sous-vêtements ! (Et de se rendre compte, à l’occasion, qu’ils sont parfois plus propres que ceux des adultes.)

  6. Belle initiative, merci. En ce moment, le logiciel libre est très attaqué par les industriels qui font beaucoup de lobying un peu partout. Alors il n’est pas inutile de rappeler qu’accéder aux données et pouvoir reproduire les résultats, maitriser et rendre transparents leur production et les outils permettant de les produire, fait partie de l’hygiène de base, au moins des chercheurs…

  7. Guillaume Allègre dit :

    Je suis d’accord (évidemment) avec Jean-Noël sur code et sous-vêtements, et on peut aller un peu plus loin.
    Non seulement, le code libre (en tous cas à source ouverte) est une méthode vertueuse au niveau de la qualité, mais encore mieux : du code libre versionné, avec un dépôt de version public serait encore plus incitatif.

    François Briatte évoque github : git et github (ou d’autres logiciels et services équivalents) permettent ce niveau de transparence : on peut savoir qui a corrigé un bug, et éventuellement qui l’a rapporté, en combien de temps il a été corrigé, etc.
    Ce n’est certainement pas encore suffisant pour stocker une énorme quantité de données, mais pour le code, les scripts, les sources des articles (en LaTeX par exemple), les outils de versionning c’est quasiment magique.

  8. Merci pour cette tribune très intéressante, vous remportez tous mes suffrages. Il me paraît essentiel de faciliter l’accès à son code, à sa méthode de travail. C’est ce que j’ai fait dans une expérimentation d’analyse textométrique de comptes rendus de l’assemblée nationale. Les billets (https://eproto.hypotheses.org/tag/mariage-pour-tous) sont liés à un entrepôt github (https://github.com/nlegrand/mariagepourtousInXML) ainsi qu’à des jeux de données pouvant être importés directement dans Philologic ou TXM. J’ai fait ça parce que ne pas le faire aurait été de l’enfumage, comme cet article sur le même sujet : aucun moyen de vérifier, de voir comment ils ont compté sans les contacter. Pour moi, si vous ne donnez pas un accès à votre méthode et vos données, votre travail est presque impossible à vérifier et je ne peux faire confiance qu’à votre honnêteté, votre intelligence et surtout votre autorité de chercheur. Veuillez m’excuser, je ne vous fais pas confiance. Je pense qu’il est nécessaire d’avoir systématiquement des réponses aux questions « pourquoi ? », « comment ? », encore plus dans une démarche scientifique.

    Le problème des sous-vêtement est important, surtout dans les SHS. Il y a une culture (un culte) du travail « parfait » qui est détestable, accompagnée de la peur maladive du plagiat. Ce n’est pas possible d’imaginer un travail en court disponible publiquement. Il faut que tout soit vérifié, revérifié par des gens importants, il faut même éviter de publier pour éviter le plagiat. On a besoin de changer les mentalités, malheureusement ce à quoi je pense semble trop radical :). C’est d’autant plus amusant, que je trouve que libérer son code protège du plagiat et donne une chance à votre code d’être critiqué, donc amélioré à un point où vous ne seriez pas arrivé seul ou avec vos relecteurs. Vos entrepôts contiennent les dates de modification de vos fichiers, vous pouvez prouver tout l’historique de votre recherche, le système rend aisé les contributions d’autres personnes permettant de solidifier votre travail. Je considère souvent que mon travail est pourri, cependant ne pas le montrer clairement, chercher à le cacher est pour moi malhonnête, honteux.

    Il y a un autre souci que le sous-vêtement, c’est le temps. Savez-vous que des calculs d’éphémérides de l’IMCCE tournent sur une machine IBM des années 1990 au code non portable, non portée et que quand cette machine tombera en panne un service de calcul de l’IMCCE ne sera plus disponible ? Je ne leur jette pas la pierre, ils n’ont pas le temps de s’occuper de ça. En fait, rendre son code portable, le diffuser, donner envie aux autres de l’essayer peut prendre trois fois plus de temps que juste écrire un code qui marche (lire à ce propos : http://www.codinghorror.com/blog/2013/07/rule-of-three.html). Comment pourrait-on demander un truc pareil à un chercheur qui est déjà surchargé et à qui finalement on ne réclame pas plus qu’un truc qui marche ? J’aborde ce sujet dans le premier billet de mon carnet (https://eproto.hypotheses.org/10). Trouver ce temps (ou employer des ingénieurs comme moi (notez mon biais) ou des organismes comme le 2e labo pour le faire), le justifier n’est pas une tâche aisée. Cependant, outre mon biais, je trouve cela indispensable pour avancer sur des bases plus saines, transparentes.

    Merci encore et bravo pour cette tribune !

    • Bastien dit :

      Je plussoie, comme on dit… et j’ajoute qu’il est grand temps qu’on apprenne un peu plus d’informatique à l’école, ne serait-ce que pour avoir des sous-vêtements un peu plus propres même dans des disciplines autres que l’informatique ! Un long combat, mais qui vaut le coup.

  9. Guillaume Allègre dit :

    Je plussoie Nicolas Legrand sur deux points (au moins).
    1) Oui, un effet de bord positif du partage+versionning de code sur un site public, c’est que le “plagiat” éventuel se démontre facilement. (même si on peut débattre longtemps de la notion de plagiat dans les publis scientifiques)

    2) Je suis absolument d’accord que les chercheurs manquent d’assistance technique. Le nombre d’Ingénieurs de Recherche et d’Ingénieurs d’Étude par chercheur me semble anormalement bas, ainsi que le recrutement (on recrute des AI pour faire un travail d’IE, des IE pour faire un travail d’IR, etc.)
    J’ai fait ma thèse dans un labo de Mathématiques Appliquées. Beaucoup de chercheurs manipulaient des gros codes de calcul immémoriaux (Fortran surtout, un peu de C++). La majorité ne savait pas se servir d’un gestionnaire de version, ne connaissait rien aux tests unitaires, et “collaboraient” en s’envoyant des fichiers modifiés (pas des diff) par mail. C’était il y a 10 ans, j’ai l’impression que ça a un peu évolué dans le bon sens (git se démocratise), mais pas assez !
    Et j’étais quand même dans un labo de maths applis, soit en gros, le plus proche possible de l’info sans être de l’info.

    Ces compétences ne sont pas dans la formation classique d’un chercheur (hors informatique), mais pourraient leur faire gagner énormément de temps et de qualité.
    Il faut des ingénieurs (AI, IR, IE) formés, qui soient capables à la fois de déployer les bons outils, de faire de la veille méthodologique, et de former à leur tour les chercheurs (dont les thésards !) à ces outils.
    Et il faudrait aussi que les chercheurs veuillent bien écouter les bons conseils qu’ils reçoivent !

  10. Anne dit :

    Très convaincant ! Je ne code pas beaucoup et me reconnais complètement dans le portrait du chercheur qui utilise Matlab parce qu’il a vu le voisin le faire et qui s’en sert avec des toolbox bricolées par d’autres voisins qui ne sont pas dans la version de base. Pour moi qui suis expérimentatrice, ce que vous suggérez est déjà du grand luxe, parce que le premier pas pour nous consisterait déjà à reproduire nos propres expériences, avant d’attendre que d’autres le fassent. Je vois peut-être le mal partout, mais j’ai l’impression que quand une expérience “marche”, beaucoup de chercheurs rédigent le papier avant même d’avoir tenté de reproduire le résultat tant espéré, qui est malheureusement parfois un pur artefact. Mais cela revient à dire qu’il faudrait un peu changer de rythme, publier moins souvent et mieux, partager plus, et ce n’est pas dans l’air du temps malheureusement.

  11. sylvie tissot dit :

    Bravo pour cet article.

    Je m’étais demandé, lorsque je lisais autrefois certains articles sur l’informatique quantique, pourquoi ils n’étaient pas associés à du code, puisque c’était le cœur du sujet.
    Votre réflexion est encore plus générale et propose une nouvelle manière de publier les résultats qui -j’espère – en convaincra plus d’un.

    J’ai eu une interrogation en lisant :
    “Une enquête récente a montré que les chercheurs interrogés choisissent en grande majorité leurs logiciels non pas en fonction de critères strictement scientifiques, mais parce qu’ils leur ont été recommandés ou parce qu’ils les ont vus utilisés dans des publications scientifiques”

    Imaginons à l’inverse qu’ils utilisent un soft très adapté mais peu connu de la communauté : est-ce que du coup ça ne limite pas la lecture des codes sources produits ?
    Comment résoudre cela ? Faut-il des “veilleurs” qui testent différents langages et d’autres qui testent les publications ? Faut-il fabriquer des “interpréteurs universels” qui pourraient essayer de faire la bascule d’un langage à l’autre si ce dernier s’avère plus pertinent ?

  12. Konrad Hinsen dit :

    Je viens de le lire avec un peu de retard au retour de vacances. C’est un très bon résumé de la situation, et je suis content de le voir dans un grand journal. Reste à voir si le grand public, qui ne connaît probablement pas le fonctionnement de la recherche, comprendra l’importance de la reproductibilité.

    D’ailleurs, il y a depuis une bonne année un mouvement de recherche reproductible en France:

    http://cascimodot.fdpoisson.fr/?q=node/51

    Une liste de diffusion sert aux échanges:

    http://listes.univ-orleans.fr/sympa/subscribe/recherche-reproductible

    Tous les chercheurs intéressés par le thématique sont invités à nous rejoindre.

  13. […] tribune dans le journal Le Monde republiée sur le site deuxième labo qui détaille les arguments en faveur de […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notre tribune sur la recherche reproductible dans “Le Monde”

Lors de notre visite au salon Innovatives SHS en mai dernier, nous avons longuement discuté avec Yvan Stroppa qui représentait RunMyCode. Le projet franco-américain RunMyCode est tout à fait emblématique de notre vision de la recherche, en ce qu’il propose une vision “augmentée” de la publication scientifique : et si à côté de votre article classique […]