Archives pour l'étiquette informatique

Similarités entre la bioinformatique et les humanités digitales (ou numériques)

Cliquez sur l'image

Cliquez sur l’image

La semaine dernière mon campus a hébergé la conférence internationale des humanités digitales (en anglais digital humanities ; en français à Lausanne humanités digitales ; en français en France humanités numériques) (blogs à voison sur hypothese.org). L’occasion de traiter un sujet dont je voulais parler depuis longtemps, les similarités entre humanités digitales et bioinformatique.

En bref, la bioinformatique est aux sciences du vivant ce que les humanités digitales sont aux sciences humaines.

Mais encore ? Eh bien dans les deux cas nous avons la nécessité de traiter intelligemment (et automatiquement si possible) des quantités rapidement croissantes de données, qui ont la particularité d’avoir été générées par des gens qui ne savaient pas qu’on aurait à les traiter informatiquement, et de travailler avec une communauté qui n’a pas une culture quantitative ni informatique très forte. Le biologiste typique aimait les sciences mais pas les maths, et l’humaniste typique n’en parlons pas.

Cela fait contraste avec d’autres domaines, comme la physique, ou certes il y a beaucoup de données, un besoin fort d’informatique, mais également une conscience forte de ces nécessités depuis longtemps, et une culture des maths et de l’informatique (la moitié de l’informatique et plus de la moitié des maths ont probablement été inventées en réponse à des défis de la physique), qui font que ceux qui génèrent les données respectent le travail de ceux qui les analysent.

De plus, en physique ou en chimie le cadre théorique est grosso-modo posé depuis longtemps, et donc quand on démarre une grosse expérience on sait ce qu’on cherche. Par contre en biologie ou en sciences humaines, parfois on génère exprès de grandes quantités de données, mais on ne sait pas encore trop quels seront les signaux intéressants, soit on doit traiter un ensemble de résultats acquis au cours du temps par différents laboratoires ou intervenants, pour différentes raisons, avec différents standards et objectifs (exemple dans ce billet).

Suite à discussion avec des collègues des humanités digitales, voici une liste de défis communs aux deux sciences interdisciplinaires :

  • La construction d’ontologies, c’est-à-dire de représentations computationnelles de domaines de connaissances.
  • L’utilisation de ces ontologies, par les spécialistes et par les autres partenaires (biologistes, médecins, littéraires, historiens, etc).
  • La gestion des méta-données, c’est-à-dire qui a collecté quelle information, avec quelles méthodes, à quelle date, avec quels standards, etc etc. Indispensable à l’analyse de données que l’on n’a pas généré soi-même, et à leur ré-utilisation, et souvent négligé voire perçu comme une contrainte inutile par ceux qui génèrent les données.
  • La récupération et la curation de l’information. Très important ! Les méthodes automatiques ont toujours des limites, et donc il faut des personnes dédiées qui collectent, expertisent et annotent les informations. Alors que beaucoup d’aspects sont davantage développés en bioinformatique (qui a une certaine avance historique quand même je pense), la curation est je pense mieux organisée et mieux perçue dans les humanités, et il existe même des masters dédiés.
  • Un sujet proche, la confiance dans les données et dans leur interprétation. Comment reconnaître et coder que certaines informations (résultats d’observations ou d’expériences, témoignages historiques ou manuscripts) soient plus fiables que d’autres ?
  • Last but not least, le défi de la communication entre les geeks et leurs confrères plus traditionnels : utilisabilité des outils, légitimité d’une façon de travailler nouvelle, confiance dans des résultats obtenus de manière peu orthodoxe, difficulté d’être perçu comme collègues et non comme techniciens ou étrangers, etc.

Pour finir, une discussion qui est propre aux humanités est le rôle du multilinguisme dans la communication académique : voir l’excellent blog de Martin Grandjean (aussi billets précédents sur l’enseignement scientifique en anglais ou français par Tom Roud et moi-même). Entre biologistes et informaticiens, on peut au moins être d’accord sur l’usage de l’anglais scientifique. 🙂

Doit-on montrer le code informatique des scientifiques même s’il est moche ?

cliquez sur l’image (puis laissez la souris au-dessus de l’image pour voir le texte alternatif) (et si vous riez, vous êtes un affreux geek)

En science on écrit beaucoup de code informatique. On écrit de gros programmes pour traiter plein de données (génomique, résultats du CERN), d’autres gros programmes pour simuler de gros modèles pour quand la réalité est complexe (le climat, les populations humaines), encore des gros programmes pour traiter des données compliquées (des structures cristallographiques). Et on écrit des petits programmes tout le temps : pour lier les gros entre eux, pour mettre les données au bon format, pour faire un petit calcul pas standard dans le logiciel, pour répéter une opération simple plein de fois, etc. (Je précise qu’il existe aussi des scientifiques qui ne programment pas. Il n’est pas question d’eux aujourd’hui.)

Au bilan, la qualité et la fiabilité de nos résultats scientifiques dépendent pas mal de tout ce code.

Et qu’est qu’on en fait, le plus souvent ? On l’écrit vite et mal, on le teste à peine, on ne le commente pas, et on le paume quelque part dans un sous-dossier de notre disque dur. La honte.

Une excellente analogie que j’ai trouvée récemment (document PDF) : peut-on imaginer que les mathématiciens publient leurs théorèmes sans montrer les preuves, parce que c’est du boulot de les mettre en forme, parce que chaque preuve est particulière à un problème et pas très utile ailleurs, c’est plus rentable de travailler sur un nouveau problème que de polir cette preuve pour publication, en fait ma preuve ne marche pas dans tous les cas mais dans le cas qui m’intéresse ça marchait, en fait c’est mon étudiant qui a fait la preuve et je ne l’ai plus, la preuve va me re-servir pour d’autres théorèmes alors je ne vais pas la donner à mes compétiteurs, les papiers avec des preuves seraient trop longs et les experts ne vont pas s’embéter à lire tout ça, ma preuve s’appuie sur un logiciel commercial (genre MatLab), vous pourrez pas vous en servir, etc.

Pour de vrai, les mathématicens publient leurs preuves, mais les scientifiques ne publient pas leur (notre) code, et nos arguments sont à-peu-près ceux ci-dessus.

Le point qui fait le plus débat est le compromis entre le travail nécessaire à rendre son code informatique présentable, et la pertinence de publier du code « sale ». Ca fait longtemps que j’ai ce billet en brouillon et je veux le publier et je ne vais pas réussir à écrire tout ce que je voudrais, alors je vais mettre quelques liens intéressants avec des résumés :

  • Iddo Friedberg a fait un excellent bilan sur son blog Byte Size Biology, avec une analogie très drôle au film « Piranha 3D », et conclut qu’en l’état il n’a pas les moyens de faire du code propre, et ne veut pas partager du code pas propre, mais propose une nouvelle initiative, le Bioinformatic Testing Consortium,
  • Dans Nature, un article Publish your computer code: it is good enough argue que même si le code n’est pas beau ni propre ni aux règles, il faut le publier, ça fait partie de la démarche scientifique.
  • Un autre article dans Nature, Computational science: …Error, prends plus ou moins l’angle inverse, et dit qu’il faut former tous les scientifiques au génie logiciel propre.
  • Un blog anonyme réagit à Iddo en disant que le but de la science n’est pas des logiciels, et donc des tests systématiques ne sont pas justifiés.
  • Un autre bloguer, Titus Brown, donne de bonnes raisons pour écrire du code proprement en respectant les règles, et donne de bons conseils pour le faire efficacement. Super citation de Darwin :

    « Ignorance more frequently begets confidence than does knowledge »

  • Sur le forum Biostar, un bioinformaticien anonyme dit que de documenter et publier son code est du même ordre de grandeur que de noter ses procédures expérimentales : indispensable. (LOLcat si vous suivez le lien)
  • John Graham-Cumming note que le problème se pose avec encore plus de force dans l’étude du climat, où l’obscurité des méthodes devient un argument politique.

Un gros problème est qu’en science on doit souvent écrire du code pour des projets qui se développent au fur et à mesure, sans savoir où on sera demain, et quel bout de code finira inutile et lequel produira le résultat critique pour la suite, voire lequel servira de base à une nouvelle méthode utilisée par ses collègues. Le fait est que dans la plupart des cas le code est vite fait – mal fait.

Il s’ajoute un autre problème : on a beau vous expliquer que si vous programmez proprement vous gagnerez du temps sur le long terme gnagnagna, vous souci premier est toujours d’obtenir le résultat. Alors on revient à #overlyhonestmethods, on fait souvent ce qu’il faut pour avancer, à coups de rubban adhésif. Mais publier son code, c’est pas un peu mettre #overlyhonestmethods dans ses articles officiels ?

A quoi je répondrais qu’il faut qu’on y passe. Trop de nos résultats sont dépendants de notre code pour le cacher. Et l’effort fait aujourd’hui payera demain, avec un code mieux débuggé et plus efficace même pour nous, avec plus de facilité à retrouver ce qu’on a fait dans 5 ans quand on aura tout oublié mais que l’article sera toujours là avec son code à-peu-près propre. Oui à-peu-près parce que je pense que pour que ça marche il faut accepter qu’on ne va généralement pas avoir du code informatique de qualité professionnelle.

Alors en pratique que faire ? Demander aux journaux scientifiques de demander le code, le demander en tant qu’expert ; publier son propre code (un peu tard pour moi, je fous plus rien en programmation) ; demander à ses collègues et étudiants de publier le leur (grosse résistance en vue) ; former les étudiants a minima à la programmation propre ; participer à des initiatives comme celle d’Iddo. Et espérer que les attitudes vont changer.

Mise à jour : @JeanFred nous signale l’existence du Science code manifesto, par le Climate Code Foundation, qui traite de ces mêmes questions.