La R&D de Servier accélérée par les bases orientées graphes
Longs à commercialiser, les médicaments nécessitent de trouver des relations entre les molécules et autres gènes. Une base de données graphes s’avère être le moyen le plus adapté, selon les chercheurs de Servier.
L’Institut de Recherches et de Développement Servier a pour objectif de découvrir de nouveaux médicaments. Dans la chaîne de commercialisation d’une molécule, il se situe très en amont, constituant le premier maillon de la chaîne. Jeremy Grignard a rejoint il y a quatre ans en tant que thésard. Il travaille au département data science et data management, dont l’objectif des calculs est de guider les projets thérapeutiques dans les différentes phases de recherche et de développement. Il s’agit d’améliorer la probabilité de succès de trouver des médicaments pertinents pour soigner des patients atteints de certains types de pathologie. Plus facile à dire qu’à faire dans un secteur dans lequel le terme Big Data prend tout son sens.
« Dans le domaine pharmaceutique, nous avons une volumétrie d’informations énorme à la base, qui a, de surcroît, une capacité sans limites à produire de nouvelles données volumineuses à travers différents domaines scientifiques », observe Jeremy Grignard. « La progression est exponentielle. À cette notion de volumétrie s’ajoute une notion d’hétérogénéité des données produites : données expérimentales qui vont être issues de différents départements, des sciences “omiques” (génomique, protéomique…), sciences cellulaires, sciences chimiques, phénotypiques structurelles, etc. », résume le data scientist.
Trouver facilement les relations entre données
C’est l’hétérogénéité des données produites par ces différents domaines scientifiques qui a motivé la création du projet Pegasus. Son objectif original était de mettre en relation toutes ces données. Plus précisément, elles proviennent de la littérature, d’expériences, ou vont être issues d’algorithmes informatiques. Alphafold, par exemple, est une application d’intelligence artificielle développée par DeepMind (appartenant à Alphabet, la société mère de Google) qui produit un ensemble de données sur la structure des protéines.
« Nous avons le pendant des données expérimentales, que l’on peut réaliser en interne, acheter ou obtenir de programmes internationaux de recherche ; et le pendant des données qu’on appelle “in silico” qui sont produites via un ordinateur », explique Jérémy Grignard.
C’est au cours de sa thèse que le laboratoire Servier a réfléchi à la manière de mettre systématiquement en relation les données afin de les exploiter comme un tout. D’où l’idée de les lier en utilisant un graphe de connaissances, plus particulièrement à l’aide de la technologie de l’éditeur Neo4j.
Les bases de données orientées graphes ont un formalisme de représentation des données différent des bases de données relationnelles. Ces SGBD SQL stockent des informations dans différentes tables liées à l’aide de clés primaires et étrangères par un schéma fixe qu’il faut définir au préalable. Si les données à lier résident dans des tables différentes, il est nécessaire d’effectuer des jointures. Les bases de données graphes, elles, représentent dynamiquement les relations entre les données, idéalement sans duplication, ni redondance. L’on peut avoir des entités biologiques ou d’autres entités reliées directement avec un lien (ou arête).
Deux formalismes pour représenter les données
Le laboratoire a d’abord créé un graphe de connaissances (Pegasus) qui fédère des données pharmacobiologiques. Il existe différentes façons de représenter des données sous forme de graphes : les graphes RDF (Ressources Description Framework) qui sont à la base du Web sémantique auquel le W3C nous a habitués, et les graphes étiquetés. En fonction de ce que l’on souhaite représenter et la manière dont le graphe sera exploité par la suite, on évalue les avantages et inconvénients des deux manières de représenter les données.
« À l’époque, nous souhaitions effectuer des requêtes assez intensives sur le graphe de connaissances et appliquer ultérieurement des algorithmes d’intelligence artificielle. Sur le graphe que nous avons développé, les graphes étiquetés sont plus pertinents pour pouvoir réaliser ces différentes tâches », précise Jeremy Grignard. « Pour l’importation de données, Neo4J avait aussi une forte capacité en termes de visualisation des très grands volumes d’informations. Il répondait à tous nos besoins. Nous avons donc conservé cette solution ».
« À l’époque, nous souhaitions effectuer des requêtes assez intensives sur le graphe de connaissances et appliquer ultérieurement des algorithmes d'intelligence artificielle ».
Jeremy GrignardChercheur et data scientist, Servier
Le laboratoire souhaitait relier l’ensemble des entités entre elles, sachant que chaque nœud peut avoir un type, c’est-à-dire qu’il représente différents concepts (gènes, transcrits, protéines, molécules chimiques, maladie, perturbateurs biologiques…). Après cette première phase de modélisation des données, il est possible de répondre à des questions techniques et commerciales.
Initialement, Pegasus était constitué d’environ 46 millions de nœuds de 66 types distincts, et un peu plus de 330 millions de relations.
Pour nourrir ce graphe, l’équipe en charge du projet a mis en place une architecture de transformation de données à l’aide du framework Python Kedro. L’objectif est d’extraire des données de bases de données sources (à travers des API, de scripts ou manuellement), puis de les prétraiter afin de former des fichiers de données intermédiaires. Ensuite, deux pipelines spécifiques servent à créer automatiquement les nœuds et les relations à injecter dans Pegasus.
Avec Neo4j, un graphe opérationnel est monté en une quinzaine de minutes. Ainsi, l’application fonctionne avec un ordinateur portable traditionnel.
Par-dessus Pegasus, les chercheurs ont déployé des applications, comme des notebooks Jupyter, des applications Python, ainsi que l’outil de visualisation Bloom de Neo4j.
Il existe aussi d’autres solutions graphes avec des bibliothèques Python, mais avec une approche où tout doit tenir en mémoire vive. L’avantage est qu’il n’y a pas besoin de développer toute une pile logicielle pour gérer l’accessibilité sur le disque et/ou en mémoire. Cela dit, avec Neo4J, les nœuds interconnectés vont être très proches les uns des autres sur le disque, ce qui augmente la rapidité en lecture et en écriture. En sus de Bloom, Neo4j accompagne son SGBD d’outils d’apprentissage automatique (Machine Learning, ML) et profond (Deep Learning).
Des résultats encourageants
Chez Servier, le graphe de connaissances et les outils déployés servent plusieurs cas d’usage dans les phases préliminaires de la recherche médicamenteuse.
Le laboratoire s’est d’abord penché sur la sélection d’oligonucléotides antisens (ASOs). En s’appuyant sur des algorithmes de Deep Learning et bio-informatiques, les chercheurs développent ces séquences d’acides nucléiques, des « fragments d’ADN » qui doivent compléter l’ARN messager et moduler l’effet de gènes « dérégulés » dans des maladies.
Or ces fragments peuvent se loger dans d’autres parties du génome et provoquer des « effets hors cibles ». Pegasus a justement été utilisé pour caractériser les effets potentiellement toxiques sur la santé humaine.
Le graphe de connaissances permet non seulement de détecter les ASOs les plus pertinents pour traiter des maladies spécifiques, mais aussi d’identifier les composants chimiquement similaires déjà créés par Servier qui pourraient provoquer les effets désirés sur ces cibles thérapeutiques. Alors qu’habituellement ce criblage aboutissait sur 1 % de découverte de hits, c’est-à-dire qu’une très faible portion des composés existants de Servier pouvait se lier à une protéine cible, la méthode mise en place par l’Institut de recherches a permis d’atteindre un taux de hit de 15 % à partir de 984 composés.
