dbparser : des bases de données pharmacologiques complexes à des workflows R reproductibles

Les grandes bases pharmacologiques sont précieuses parce qu’elles conservent des relations complexes entre médicaments, cibles, voies biologiques, produits, effets indésirables et interactions. C’est aussi ce qui les rend difficiles à analyser. DrugBank se présente sous la forme d’un XML profondément imbriqué ; OnSIDES sous forme de fichiers CSV relationnels ; TWOSIDES sous forme de données d’interactions compressées. dbparser transforme ces sources différentes en objets R cohérents et en workflows d’intégration traçables.

01Le problème est structurel, pas cosmétique

Une base pharmacologique n’est pas une feuille de calcul avec trop de colonnes. Les fiches de médicaments sont reliées à des cibles, enzymes, transporteurs, voies biologiques, produits, références et identifiants externes. Un parseur qui se contente d’aplatir le fichier peut faciliter son chargement tout en détruisant silencieusement les relations qui donnent du sens aux données.

Les sources ne partagent ni les mêmes formats ni les mêmes identifiants. DrugBank utilise une vaste hiérarchie XML. OnSIDES distribue plusieurs tables CSV issues des notices de médicaments. TWOSIDES fournit une représentation compressée des effets indésirables associés à des paires de médicaments. Des scripts ad hoc peuvent suffire pour une analyse, mais ils masquent souvent les hypothèses de jointure, les versions et le traitement des valeurs manquantes.

02Un objet commun sans effacer la source

dbparser introduit le dvobject — un objet drugverse implémenté comme une liste R avec des modes d’accès cohérents. Il conserve des tables tidy pour l’analyse, des métadonnées sur la version de la base et le parsing, ainsi que des correspondances décrivant les relations entre les tables.

Pour une version de DrugBank, l’objet peut exposer les informations sur les médicaments, les sels, les produits, les références et les structures liées aux carriers, enzymes, targets et transporters. Lorsque plusieurs sources sont fusionnées, le même objet reçoit des composants imbriqués et des tables intégrées au lieu de devenir un ensemble de jointures non documentées.

03Du parseur au moteur d’intégration

La version actuelle du package utilise DrugBank comme noyau mécanistique. OnSIDES apporte les effets indésirables extraits des notices de la FDA, tandis que TWOSIDES apporte les effets associés à des associations de médicaments. Ce choix d’architecture en étoile réduit le nombre de correspondances d’identifiants à maintenir et rend le chemin d’intégration explicite.

Ce choix comporte une contrepartie : les workflows multi-bases dépendent des identifiants et des correspondances de DrugBank. Mais cette contrainte est visible et testable, plutôt qu’enfouie dans un notebook ponctuel.

04L’ingénierie logicielle autour du parseur

Un package de recherche utile ne repose pas uniquement sur des fonctions de parsing qui marchent. Il lui faut une interface publique stable, des tests, de la documentation, des métadonnées, des exemples, des versions identifiables et un processus de revue. dbparser est distribué sur CRAN, documenté par rOpenSci, publié sous licence MIT et maintenu dans un dépôt public.

Le package a fait l’objet d’une évaluation par les pairs chez rOpenSci, et son article logiciel a été publié dans le Journal of Open Source Software en février 2026. Ce parcours compte parce qu’il rend les affirmations de qualité vérifiables : dépôt, fil de revue, archive, documentation et suivi des problèmes sont publics.

05Un workflow compact et reproductible

Le code ci-dessous montre l’architecture sans la masquer derrière une interface graphique. Chaque source est analysée séparément. Les objets obtenus sont ensuite fusionnés par des opérations explicites et chaînables. Le code est conservé exactement tel qu’il apparaît dans la documentation du package.

library(dbparser)
library(dplyr)

drugbank_db <- parseDrugBank("data/drugbank.xml")
onsides_db  <- parseOnSIDES("data/onsides/")
twosides_db <- parseTWOSIDES("data/TWOSIDES.csv.gz")

final_db <- drugbank_db %>%
  merge_drugbank_onsides(onsides_db) %>%
  merge_drugbank_twosides(twosides_db)

head(final_db$integrated_data$drug_drug_interactions)

06Du projet étudiant à l’infrastructure de recherche

CRAN enregistre la première version de dbparser en décembre 2018. L’archive publique montre ensuite une succession de versions maintenues, et non un dépôt isolé. Avec la version 2.2.1 publiée en janvier 2026, le package dépasse le seul parsing de DrugBank et prend en charge des workflows intégrés de pharmacovigilance sur trois sources.

La documentation du projet recense plus de dix publications évaluées par les pairs dans des domaines allant du repositionnement de médicaments aux biomarqueurs, à la modélisation de voies biologiques et à l’analyse d’essais cliniques. L’histoire forte n’est donc pas seulement qu’un étudiant a écrit un parseur : c’est que ce travail a résisté aux usages d’autres équipes, aux évolutions des bases sources, à la revue du package et à la maintenance dans le temps.

07Le diplômé derrière le projet open source

Mohammed Ali est diplômé de DSTI, auteur et mainteneur de dbparser. Ali Ezzat est coauteur du package et de l’article JOSS. Leur trace publique permet d’examiner le logiciel à plusieurs niveaux : version stable sur CRAN, manuel de référence, documentation rOpenSci, dépôt source, discussion de revue et publication JOSS archivée.

Cette ouverture fait partie du résultat d’ingénierie. Un outil de recherche reproductible doit permettre de retracer non seulement le résultat d’une analyse, mais aussi la version du logiciel, la version des données sources et les décisions qui ont transformé l’une en l’autre.

Logiciel, documentation et publication

Sources et note éditoriale : Article élaboré à partir de l’ancienne présentation DSTI du projet étudiant, d’un manuscrit fourni et des sources actuelles de CRAN, rOpenSci, du dépôt et de JOSS. Les noms techniques, fonctions du package, code et titres de publications sont conservés exactement.