Archives pour la catégorie informatique

Pacman ! Avec de l’ADN et des acides aminés !

cliquez sur le lien, c'est trop beau, trop cool, trop tout, allez sérieux

cliquez sur le lien, c’est trop beau, trop cool, trop tout, allez sérieux

Syed Hussain Ather, un étudiant d’un collègue américain (Matthew Hahn, mentionné ici), vient de rendre disponible sur github un programme Python rigolo qui reproduit PacMan mais en version biologie moléculaire : on mange de l’ARN, et on fabrique des protéines.

https://github.com/HussainAther/dnapacman

Pour traduire l’ADN en protéines, il est en effet transcrit en ARN. Les nucléotides d’ADN sont A, C, G et T (comme dans « Bienvenue à GATACA »), alors que ceux de l’ARN sont A, C, G, U (donc « Bienvenue à GAUACA »). L’ARN peut alors être traduit en protéines, composé de 20 acides aminés. Pour faire correspondre 4 nucléotides à 20 acides aminés, il y a un code basé sur des triplets de nucléotides. En effet, 41 = 4, pas assez ; 42 = 16 pas assez ; 43 = 64, davantage que 20, cool. Ces triplets s’appellent « codons ». (Notez que ça veut dire qu’il y a plusieurs codons pour un même acide aminé.) Pour que la traduction démarre, il faut un codon « start », AUG (codé par ATG dans l’ADN), qui code pour l’acide aminé méthionine (symbole M). Il y a dans le code standard trois codons « stop », qui arrêtent la traduction.

code génétique de Wikipedia

code génétique standard (depuis Wikipedia)

Dans DNA-PacMan (qui à mon avis devrait s’appeler RNA-PacMan, mais passons), il faut donc se balader en mangeant des nucléotides, et dès qu’on a mangé un AUG on commence à fabriquer des acides aminés, jusqu’à manger un codon stop … ou se faire manger par un fantôme.

C’est un programme simple qu’il faut lancer directement avec Python, et les résultats s’affichent dans une console terminale. Ce qui accentue encore le coté geek. 😉

pacman1pacman2

Informatique, biologie et 6 millions de danois : les patients médicaux ont une histoire

cliquez sur l'image

cliquez sur l’image

Ceux qui me suivent sur Twitter ont souffert la semaine dernière, vu que j’étais à une conférence de bioinformatique, que j’ai live-tweetée abondamment. J’ai appris pas mal de choses intéressantes, et je voudrais revenir si j’ai le temps sur plusieurs des résultats intéressants. Et d’abord la conférence de Søren Brunak, bioinformaticien médical danois :

Creating disease trajectories from big biomedical data

basé notamment sur son article :

Temporal disease trajectories condensed from population-wide registry data covering 6.2 million patients. Jensen et al 2014 Nature Comm 5: 4022

Commençons par quelques points mis en avant sur Twitter par moi ou d’autres :

Le concept clé pour Søren est celui de « trajectoire » : un patient médical a un passé et un avenir, qui devraient être pris en compte dans son diagnostic et son traitement. Il veut donc utiliser les données qu’il a à disposition au Danmark pour déterminer statistiquement les trajectoires probables, et la manière dont elles influencent les traitements qui marchent ou pas, les chances de survie ou de complication, etc.

L’équipe de Søren a utilisée les données complètes des hôpitaux danois de 1996 à 2010, soit 6,2 millions de patients avec 65 millions de visites. On sait dans quel ordre un patient a eu quels diagnostics ou traitements, et avec quelles conséquences. Ils ont découvert 1171 « trajectoires » significatives. Une trajectoire est une suite de diagnostiques ou d’actes médicaux qui se suivent dans un certain ordre davantage qu’attendu au hasard.

Par exemple : ncomms5022-f2

En (a) on voit des séries de maladies qui se suivent fréquemment, liées au cancer de la prostate. En (b), ces séries sont regroupées de manière à montrer toutes les trajectoires de manière synthétique.

Un point important est que ceci est déterminé automatiquement, en utilisant d’abord une corrélation assez simple entre diagnostics. La probabilité d’observer une corrélation au hasard est estimée en ré-échantillonnant les données (en mélangeant les observations au hasard en d’autres termes) des millions de fois, et en corrigeant pour le fait d’avoir effectué des tests multiples. Comme ça prend du temps de calcul, ils ont fait ça sur une partie des données, puis utilisé ces résultats pour valider une approche plus rapide. Ils ont assemblé les paires de diagnostics en séries en prenant simplement les chevauchements (si on a A->B et B->C, alors on a A->B->C), avec à nouveau un test pour vérifier la significativité statistique ; pour limiter le bruit statistique, les trajectoires avec moins de 20 patients au total ont été éliminées de l’analyse. Les trajectoires sont regroupées, comme montré en (b) ci-dessus, par Clustering Markovien. C’est là que j’apprends en vérifiant mes sources que cette approche très utilisée en bioinformatique n’a pas été vraiment publiée hors d’une thèse de maths. La page de référence étant celle du logiciel fourni par ledit mathématicien : MCL. A la base, la méthode cherche dans un graphe (des points liés par des traits, voir figure ci-dessus) des « chemins » plus probables si on marche au hasard dans le graphe, lesquels chemins correspondent à des sous-ensembles du graphe qui sont mieux connectés. Donc à des sous-ensembles, par exemple de diagnostiques, qu’il faut regrouper. CQFD. Y a d’autres trucs amusants dans leurs études, comme le développement d’une méthode informatique permettant de comprendre automatiquement les textes écrits par des médecins en danois, y compris les négations (très importantes dans les diagnostiques).

Allez, deux plus gros graphes :

ncomms5022-f3

Là on peut voir par exemple en (a) que la plupart des maladies suivant une athrosclérose, et pouvant être considérées éventuellement comme des complications, ne viennent comme complications plutôt d’une Bronchopneumopathie chronique obstructive (COPD en anglais), qui suit souvent mais pas toujours l’arthrosclérose.

ncomms5022-f4Bon avouez que c’est joli.

Sinon, pour montrer encore un peu ce que l’on peut trouver dans ces données et l’importance de la médecine personalisée, voici les incidences de quelques classes de diagnostiques en fonction du sexe et du type de viste : patient hospitalisé (in-patient), patient en visite libre (out-patient), urgence (emergency) :

ncomms5022-f1Tiens, les femmes ont plus souvent des diagnostics d’accouchement (en vert) que les hommes, et sont généralement hospitalisées à ce moment-là. 😉 Et les blessures (en rouge) sont plutôt le fait d’hommes de 21 ans, et se retrouvent aux urgences. Comme quoi ça marche ces stats.

Comme vous l’aurez peut-être remarqué dans les tweets ci-dessus, cette étude a été permise par une législation très libérale en ce qui concerne la collecte et l’utilisation des données personnelles au Danmark. Il n’est pas évident que de telles études soient portables à d’autres sociétés, moins enclines à faire confiance à leur état et leurs institutions. Il n’est en fait pas évident pour moi que ce soit souhaitable, contrairement à ce que souhaite clairement Søren Brunak. Mais si de telles études ne sont pas répétées, il y a le risque d’avoir une information très biaisée par les risques génétiques des danois, et surtout par leur mode de vie, qui se caractérise apparemment par une nourriture grasse et peu d’exercice. Søren a donc admis bien volontiers que, même si les résultats ont été partiellement vérifiés en Grande Bretagne et aux Pays Bas, il seraient difficiles à généraliser à un pays méditerranéen ou d’Asie de l’Est, par exemple.

Il n’en reste pas moins que les grandes lignes de cette étude sont probablement très généralement correctes, et qu’une information partielle de ce type vaut mieux qu’aucune information à mon avis. Une complainte fréquente des patients des hopitaux et médecins traditionnels est que leur histoire n’est pas prise en compte, d’où une tendance à aller chez des charlatans qui font n’importe quoi, mais écoutent attentivement toute l’histoire et rassurent sur l’avenir. On voit ici que l’exploitation intelligente de grandes quantités de données médicales a le potentiel de permettre une prise en compte rationnelle et réellement utile des histoires des patients.

Note de service : les commentaires ne vont pas fonctionner ce mercredi-jeudi 17-18 juin, en raison de maintenance du serveur cafe-sciences.org.

Update: following demand on Twitter, an English translation is available here.

Pourquoi je suis favorable à l’enseignement de la programmation à l’école

Cliquez sur l'image

Cliquez sur l’image

C’est un débat qui revient régulièrement, et pour une fois avec une certaine symétrie des deux cotés de l’Atlantique : doit-on enseigner la programmation à l’école ?

Les arguments contre, je l’avoue, me convainquent assez peu : la programmation n’est pas vraiment une discipline au même titre que les maths ou la littérature (mais on enseigne aussi la flute à bec, la cuisine et le sport que je sache – et si la définition d’une discipline c’est d’être patiné par les ans, par définition on n’en n’aura jamais de nouvelle) ; pas tout le monde aura besoin de programmer (bin pas tout le monde aura besoin d’avoir lu Victor Hugo et de savoir calculer une dérivée) ; les profs ne sont pas formés (à nouveau, avec cet argument on n’aura par principe jamais de nouvelles matières). L’argument le plus étrange pour moi, mais qui apparemment fait mouche : c’est pas avec ça qu’on va résoudre tous nos problèmes ! (Beaucoup de discussion en suivant ce lien ; l’article lui-même me paraît poser de fausses dichotomies ; et je précise que je n’ai pas lu tous les commentaires.) Euh non, mais si on n’a rien le droit de faire si ce n’est pas la seule solution à tous nos problèmes, c’est un peu limitant (ça me rappelle certains débats sur le riz doré).

Pour être clair : le manque de profs est un problème, mais si c’est le principal problème, alors il n’y a pas d’opposition de principe, et c’est un problème auquel il est possible de chercher des solutions : formation de profs volontaires (et je ne vois vraiment pas pourquoi ça serait limité ni même davantage encouragé pour les profs de maths), embauche en temps partiel d’étudiants, flexibilité sur les diplômes si expérience professionnelle, … bon après je ne m’aventure pas dans les débats sur les statuts de fonctionnaires en France, mais ce n’est plus une question de principe donc.

Alors pourquoi suis-je favorable à l’enseignement de la programmation à l’école ?

D’abord, l’informatique me paraît une matière importante, et c’est en programmant qu’on l’appréhende le mieux. De même qu’on fait des expériences en chimie et physique, des calculs en maths, des rédactions en français, c’est en programmant qu’on comprend à la base l’informatique. Ceci n’exclut pas d’aller plus loin et plus théorique pour ceux qui le veulent, mais il me semble que la compétence de base s’acquiert vraiment au pied du mur en devenant forgeron (ou quelque chose comme ça). J’ai eu une discussion Twitter avec un collègue bioinformaticien à ce propos, où il défendait qu’apprendre à programmer était comme apprendre la mécanique automobile plutôt que la physique. Je maintiens que c’est plus comme écrire des rédactions ou des dissertations, ou résoudre des calculs. De plus, l’informatique est quand même à mon avis à la fois une science et une technologie (voir les avancées et théoriques et pratiques d’un très bon informaticien dans ce billet). (La bioinformatique aussi d’ailleurs.)

Ensuite, lorsque l’on sait programmer, je pense que même si l’on ne programme pas (ou plus) en pratique, on en retire la compréhension de deux choses importantes :

  • On comprend mieux l’intuition du programmeur, et donc on comprend mieux comment utiliser les logiciels et on comprend mieux ce que l’on peut demander ou pas à l’informatique. On comprend ce qui doit forcément être sauvé dans un fichier, sinon ça ne serait pas gardé, ce qui devrait logiquement être modifiable parce que c’est facile, et ce qui n’est pas vraiment possible. C’est facile de se moquer du maire de New York qui affirme vouloir apprendre à programmer, parce qu’en effet dans son travail il ne doit pas en avoir besoin. Mais s’il comprend mieux ce qu’il peut demander, ce qui améliorerait la vie et serait vraiment facile à faire, ce serait un sérieux progrès pour la gestion des grandes villes à mon avis. Et juste pour prendre en main un nouveau logiciel, ou un nouvel appareil (iBidule ou autre), de comprendre ce qu’est un programme et comment ça marche est un sérieux plus. Vous comprenez ce que ça veut dire, que les apps soient « sandboxés » sur un iphone ? Sans savoir programmer, cela reste forcément un peu obscur je pense.
  • On comprend au moins intuitivement plein de notions qui sont en général pertinentes à notre relation avec le monde, y compris hors informatique. C’est un bénéfice de devoir formaliser la manière de penser et d’exécuter. Ce que sont un algorithme (comment résoudre une tache), une heuristique (une solution approximative, rapide et qui marche la plupart du temps), que de mauvaises données ne donneront pas de bonne solutions (Garbage in garbage out), qu’un ordinateur ne peut pas « comprendre » au même sens qu’un humain, etc etc, sont des notions à mon avis fondamentales. Notions que l’on peut bien sur pousser pour ceux qui le choisissent, mais dont on peut donner une intuition à la plupart des gens en leur faisant utiliser.

Un bénéfice je trouve moins critique mais quand même appréciable est de pouvoir utiliser l’informatique dans la zone grise qui n’est pas vraiment de la programmation au sens strict, mais manipule les mêmes objets et concepts : éditer du HTML pour une page web ou un blog, éditer le code dans Wikipedia, utiliser un logiciel de statistiques avancé comme R, écrire des macros Excel, etc.

Débats secondaires : à quel niveau à l’école ? Dès 6 ans, 10 ans, ou seulement à 17 ans ? Et quel languages ? Il me semble qu’il faut d’abord être d’accord sur les objectifs avant de s’occuper des moyens de les réaliser. En l’état des choses, je vote 10-12 ans, programmation de robots puis Python, mais je suis très ouvert à ce niveau-là. 🙂

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. 🙂

Réflexions sur l’apport de l’informatique à la bioinformatique

cliquez sur l'image

cliquez sur l’image

J’ai récemment été au séminaire de retraite GNOME (Gonnet is Not Only Molecular Evolution) de Gaston Gonnet, un grand bonhomme de l’informatique (Google Scholar), notamment connu pour le logiciel de calcul Maple, et ces 25 dernières années pour ses contributions parfois remarquées à la bioinformatique et à l’évolution moléculaire. Le séminaire a inclus des informaticiens hard-core aussi bien que des collaborateurs biologistes, et bien sur des bioinformaticiens, certains formés par Gaston à l’interface interdisciplinaire. C’est l’occasion de réfléchir à l’interaction informatique-biologie, et notamment à l’apport de l’informatique.

Bien sur, les ordinateurs plus puissants, les languages de programmation de haut niveau, et les systèmes de gestion de données, sont utiles à la biologie, mais ce n’est pas de ça que je veux parler. La recherche en informatique, ce sont de nouveaux algorithmes, des démonstrations de complexité, voire de nouveaux languages de programmations ou manières de représenter l’information.

Prenons l’exemple de la première contribution (remarquée) de Gaston à la bioinformatique : la matrice de Gonnet (Gonnet et al 1992 Science 256: 1443-1445).

La contribution a été remarquée à la fois grâce au résultat, et à cause du ton du papier, qui contient la phrase « The parameters provide definitive answers to two fundamental questions concerning protein alignment: What does a mutation cost? and What does a gap cost?« . Cette phrase n’est probablement pas due à Gaston (communication personnelle), mais elle est quelque part emblématique d’un certain type de relations entre bioinformaticiens issus de la culture de la démonstration de l’informatique et des maths (voir aussi Lior Pachter) et bioinformaticiens issus de la culture empirique de la biologie.

Bref, un peu d’histoire. Le type de matrice dont on parle ici est un genre de tableau qui donne les probabilités de changement d’un acide aminé en un autre lors de l’évolution des protéines. Les protéines sont des chaînes d’acides aminés, qui forment un « alphabet » de 20 lettres. Une protéine peut changer par mutation soit en remplaçant un acide aminé par un autre, soit par délétion ou insertion d’acides aminés. Un acide aminé peut être remplacé par un autre selon une probabilité qui dépend à la fois de propriétés chimiques et du code génétique (certains changements sont plus faciles à obtenir par hasard), et de l’impact fonctionnel sur la protéine (certains changements ont plus de chances de casser la fonction de la protéine, et sont donc éliminés par la sélection naturelle – ce qui diminue la probabilité de les observer en pratique). Dans les années 1960, celle qui a probablement fondé la bioinformatique sans ordinateurs, Margaret Dayhoff, a eu l’excellente idée de comparer beaucoup de séquences de protéines homologues (beaucoup à l’époque : quelques dizaines) (homologues : en gros la même protéine dans différentes espèces ; voir ce billet), et de compter les changements entre tous les types d’acides aminés. Ce qui lui a permis de construire la première matrice de probabilités de changements entre acides aminés, connue comme PAM (point accepted mutation). Y a une explication plus détailée sur le blog bioinfo-fr.

Etape 1 donc : intuition du biologiste, qui lui permet d’obtenir un résultat et un outil utiles.

Ensuite, des informaticiens ont démontré la manière optimale d’aligner des protéines pour savoir quels acides aminés comparer de manière mathématiquement correcte (Needleman-Wunsch). Démonstration cool, bien que limitée à l’époque par la puissance des ordinateurs : les algorithmes exacts sont lents. Mais ces démonstrations ont formé la base de beaucoup de travail suivant.

Etape 2 : des informaticiens démontrent des théorèmes et trouvent des algorithmes exacts, quoique souvent inutiles en pratique (provoc assumée).

Dans les années 1980, Gaston Gonnet avait travaillé sur des algorithmes rapides et efficaces pour chercher dans tous les mots de l’Oxford English Dictionnary. Il a alors été contacté par un biologiste assez original et brillant, Steven Benner, qui lui a proposé, et je cite, « de travailler sur des données intéressantes » (par opposition au dictionnaire apparemment). Ils ont relevé le défi de mettre à jour les vieilles matrices de Dayhoff, avec bien davantage de données, en utilisant les algorithmes de Gaston pour les dictionnaires. Ils ont ainsi calculé la matrice de Gonnet, qui inclut non seulement une mise à jour des probabilités de changement entre acides aminés, mais des estimations des probabiliés d’insertion et de délétion (les « gaps » de la citation ci-dessus) grâce également à l’emploi de la méthode Needleman-Wunsch.

Etape 3a : les informaticiens répètent le travail des biologistes – bioinformaticiens (Dayhoff), mais bien plus efficacement.

Etape 3b : la collaboration entre biologistes et informaticiens qui se s’écoutent et travaillent efficacement ensemble déchire tout.

A noter aussi qu’une partie de l’apport de Gaston était dans la manière de représenter l’information dans un ordinateur pour des recherches rapides, et qu’il a implémenté ses méthodes dans un language qu’il a développé, appellé … DARWIN.

Voilà bien sur c’est un cas particulier, mais souvent comme ici le point de départ d’une nouvelle approche vient de l’intuition des biologistes, elle est rendue efficace par les informaticiens, et quand on travaille vraiment ensemble on fait de grandes choses.

En plus ils m’ont donné un t-shirt à la conf, avec un gnome cool, et j’ai appris que « gnomes » était un surnom des banquiers zurichois.

Mise à jour : des liens pertinents via Christophe Dessimoz :

Notes sur ma semaine en sciences 4

cliquez sur l'image

cliquez sur l’image

  • Un bilan de 451 additifs alimentaires autorisés aux Etats-Unis entre 1997 et 2012 indique que l’expertise n’a jamais été indépendente, et qu’elle a été faite par un employé de la compagnie concernée dans 22% des cas. Clairement, un système à revoir. Article d’accès libre.
  • J’ai commencé à écrire ma prochaine demande de financement au Fonds national suisse pour la science (je sais, pour un français dire « fonds national » ça sonne bizarre). On peut poser la question de la pertinence de l’écriture de ces projets, sachant que le meilleur prédicteur du succès d’un chercheur est sa productivité passée. Donc en regardant la mienne, on peut raisonablement s’attendre à ce que premièrement je continue à obtenir des résultats et à les publier, deuxièmement ces résultats ne changent pas la face du monde, et troisièmement qu’ils soient quand même utiles et cités par des collègues. Mais cet exercice est quand même important et utile. Cela me force à réfléchir à la cohérence de ce qu’on veut faire, au contexte international, et à convaincre des collègues de la pertinence de nos projets. Je pense que cela vaut le coup.
  • Un compte-rendu intéressant d’analyse de la vigueur hybride dans le maïs cultivé : le fait qu’on obtient de meilleurs rendements en croisant deux souches pures bien choisies qu’en sélectionnant une souche seule (et c’est pourquoi la plupart des paysans rachètent des graines tous les ans, OGM ou pas).
  • Un collègue améliore la productivité du manioc en Colombie grâce aux champignons microscopiques, j’y reviendrais. Communiqué de presse, article libre d’accès.
  • Une nouvelle technique de compression de données spécifique aux génomes humains permet de ternir l’information génomique d’une personne en 2,5 Mb. A noter que cela suppose qu’on ait un génome de référence et qu’on ne code que les différences, donc le point de départ n’est que de 84 Mb, pas 3,2 Gb. C’est quand même 37% de mieux que le record précédent. Article (accès fermé).
  • Un prototype de riz OGM qui fournit un anticorps contre un virus mortel (rotavirus) dans le Tiers Monde (news dans Nature). Mais me direz-vous, y a qu’à les rendre riches au lieu de faire des biotechnologies (y a vraiment un commentaire comme ça hélas). Sérieusement, c’est encore loin de l’application sur le terrain, mais c’est une approche originale et intéressante. Le risque bien sur c’est qu’alors que c’est relativement facile d’adapter un vaccin aux changements d’un virus, un OGM qui produit un anticorps donné risque d’être compliqué à mettre à jour quand le virus va évoluer une résistance.
  • C’est officiel : si vous utilisez Gmail, vous abandonnez toute prétention à avoir une correspondence privée. Comme remarqué par Nicolas Le Novère, cela s’applique à toutes les communications passant par des tiers (en tous cas aux Etats-Unis).
  • Commentaire Slashdot que je trouve intéressant : la carrière de Steve Jobs aurait consisté à rendre réelles les promesses de la « mère de toutes les démos« .
  • Intéressant par rapport au débat sur le libre accès aux publications scientifiques (open access) : alors que certains collègues arguent que le libre accès pose problème dans le Tiers Monde (parce qu’il faut payer pour publier), une université nigérianne a arrété ses abonnements (qui coutent très cher) et se repose presque exclusivement sur le libre accès. Interview dans The Guardian.
  • Un billet de blog de Edzart Ernst, professeur de médecines alternatives, qui explique que sa formation de médecin ne comprenait pas d’apprentissage du pensée critique, et que c’est ses tentatives de comprendre l’homéopathie qui ont formé son esprit critique et son scepticisme.
  • Dan Graur attaque une étude de génomique, et l’auteur répond. Presque comme des grandes personnes. Blog de Graur.
  • Le poster présentant notre base de données Bgee sur l’expression des gènes et l’évolution pour la conférence ESEB (European society for evolutionary biology) est dans FigShare.
  • Ca nous est tous arrivés, mais Rosie Redfield le discute publiquement (comme toute sa science d’ailleurs) : des compétiteurs qui « oublient » de citer votre travail quand ils se basent dessus pour le leur.
  • Un petit ralage sur mon blog anglophone concernant l’abus du terme « dogme » dans les publications scientifiques.
  • Dans un parallèle que je trouve intéressant avec la conclusion de mon billet de lundi sur la génomique des cellules HeLa, un billet de blog qui note que les « Big Data » nous retournent à une vie de village sans vie privée.

Notes sur ma semaine en sciences

Cliquez sur l'image

Cliquez sur l’image

Je commence une nouvelle formule : il y a régulièrement des choses que j’apprends ou que je vois dans ma semaine de travail, qui feraient de bons billets de blog mais que je n’aurais pas le temps de développer, ou qui seraient juste sympa à partager rapidement avec un public plus large mais sans faire un billet.

Je vais donc essayer de partager des notes rapides plus ou moins tous les vendredis. Les billets plus consistents, qui étaient généralement le vendredi, paraîtront dorénavant le lundi. On va voir si j’arrive à tenir. A noter qu’il risque d’y avoir une part de redondance avec mon fil Twitter, mais ici je ne suis pas limité à 140 caractères et ce sera tout en français. Par rapport aux billets habituels du blog, je vais aussi mettre ici des infos sur la vie du labo : nos articles, nos financements, les conférences, etc.

Voici donc la première de cette séries de notes (un peu longue parce que j’ai des trucs de la semaine d’avant aussi).

  • Des chercheurs qui travaillent sur les phéromones de papillon ont mis en données supplémentaires une super BD originale qui illustre leurs résultats : http://www.plosgenetics.org/article/info%3Adoi%2F10.1371%2Fjournal.pgen.1003620#s5. Mon sup data préféré précdent était la « Amphioxus Song » inclue avec le génome d’amphioxus (où je suis co-auteur mais ça n’est pas moi qui ait mis la chanson) : www.nature.com/nature/journal/v453/n7198/suppinfo/nature06967.html
  • Quand on donne de l’alcool à des mouches mâles, elles cherchent à s’accoupler avec tout ce qui bouge, mais leur taux de succès auprès des femelles diminue (entendu dans un séminaire, je n’ai pas la ref). Toute ressemblance avec d’autres espèces…
  • Les illustrations du séminaire anti-ENCODE de Dan Graur (voir ce billet) sont en ligne et sont très droles (humour bio-geek) : twileshare.com/askq
  • J’ai écrit sur mon blog en anglais une explication de « l’histoire derrière le papier » pour un article récent de mon groupe : Story behind the paper: The hourglass and the early conservation models – co-existing evolutionary patterns in vertebrate development.
  • Découvert via un article dans The Scientist une base de données de stockage et analyse simple de profils métaboliques (composés chimiques dans un mélange complexe comme notre sang), avec comme exemples de démo la comparaison Coca-Cola / Pepsi, et la comparaison de deux bières. La base de données est gratuite mais il faut créer un login : xcmsonline.scripps.edu
  • Un prof d’informatique propose un système centralisé pour déposer et maintenir le code informatique pour que les expériences computationnelles sont reproductibles pour toujours : son billet de blog, son site recomputation.org, et un précédent billet à moi sur le sujet. Voir aussi l’excellente tribune dans Le Monde de nos collègues du C@fé.
  • Un étudiant m’a demandé des recommendations de livres pour commencer la bioinformatique. Voici mes préférés (je n’ai pas acheté de livres récemment, donc ça date un petit peu, mais une recherche web retrouve toujours le livre de Mount de 2004 comme un favori de bcp de gens) : Bioinformatics and molecular evolution, Paul G. Higgs and Teresa K. Attwood (ISBN 1405106832) ; Bioinformatics: sequence and genome analysis, David W. Mount (ISBN 0879697121) ; Building Bioinformatics Solutions with Perl, R and MySQL, Conrad Bessant, Ian Shadforth, and Darren Oakley (ISBN 978-0-19-923023-5).
  • Quelqu’un a enfin fait le test de « fonction » d’ADN aléatoire ! Il faudra que je revienne dessus. Billet de blog au Finch & Pea, article dans PNAS, mon billet précédent sur le sujet. Mais quand même vous voyez comme c’est cool la science, on se dispute, on fait une nouvelle expérience pour tester qui a raison, et on avance ! Presque comme des adultes.
  • Bilan de ma semaine OGM : l’important ça n’est pas de comprendre la biologie, l’important ça n’est pas de sauver des vies, l’important ça n’est pas de préserver l’environnement, l’important c’est d’écrire des titres de billets respectueux et polis que personne ne lira (et surtout ne jamais utiliser le mot « bobo »).

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.