Le client et le contexte
Ochre Bio est une biotech fondée en 2019 à Oxford. Elle développe des thérapies ARN contre les maladies du foie. Ses laboratoires produisent beaucoup de données génomiques, et une équipe de biologistes computationnels les analyse pour repérer les gènes qu’un traitement pourrait cibler.
Pour consulter ces résultats, l’équipe avait commencé une application R Shiny. Un scientifique y saisit le nom d’un gène et obtient un rapport qui montre dans quelles cellules du foie ce gène s’exprime, à quelles observations cliniques il est associé et ce que provoque son extinction.
On a rejoint le projet en 2022, pour l’interface. Jörn Schmiedel, responsable de l’informatique scientifique d’Ochre Bio, décrivait l’objectif dans son témoignage.
Ce que nous voulions, c’était développer une interface qui agrège toutes nos données et qui soit capable de les présenter à tous les scientifiques de l’entreprise, mais aussi à des personnes externes, à toutes les parties prenantes, aux investisseurs, et plus globalement au public.
Notre travail s’est ensuite étendu de l’interface au back-end, puis à l’administration du compte AWS, et l’application a pris le nom d’OBELiX.
Le problème
Fin 2023, Ochre Bio prévoyait d’ouvrir OBELiX l’année suivante à des laboratoires pharmaceutiques partenaires. Leurs chercheurs allaient se connecter à l’application pour consulter les données d’Ochre Bio.
Ce nouveau public changeait les exigences. Chaque partenaire ne devait voir que les données auxquelles il avait droit. L’application devait répondre vite, y compris quand plusieurs équipes s’y connectaient en même temps. L’infrastructure qui l’héberge devait satisfaire les règles de sécurité d’un grand laboratoire.
Ce qu’on a fait
Des graphiques calculés à l’avance. Pour que l’application réponde vite à plusieurs équipes en même temps, on en a sorti le calcul des graphiques. Des tâches automatiques produisent chaque graphique de chaque gène et l’enregistrent dans un espace de stockage, S3. Quand un utilisateur ouvre un rapport, l’application n’a plus qu’à afficher des graphiques déjà prêts.
En contrepartie, tout doit être produit avant l’ouverture. La base compte 63 187 gènes, ce qui faisait environ 630 000 graphiques avec cinq types de graphiques et deux groupes d’utilisateurs au départ. On a donc découpé le calcul pour que chaque graphique puisse être refait seul, en quelques secondes, et une tâche qui échoue est relancée automatiquement.
Des droits réglés par groupe. Chaque utilisateur appartient à un groupe, celui d’Ochre Bio ou celui d’un partenaire. Une table indique, pour chaque groupe, les sections du rapport auxquelles il a droit. L’interface s’en sert pour masquer les sections non autorisées, et les tâches de calcul pour ne pas en produire les graphiques. Un graphique auquel un partenaire n’a pas droit n’existe donc pas pour son groupe. Les données sont elles aussi rangées dans un dossier par groupe.
Un hébergement reconstruit sur AWS. On a refait l’infrastructure pour qu’elle satisfasse les règles de sécurité d’un grand laboratoire. L’environnement de test et la production vivent dans deux comptes AWS séparés, et une modification est vérifiée dans le premier avant d’atteindre le second. Toute l’infrastructure est décrite dans du code, avec CloudFormation, ce qui permet de la recréer à l’identique et de relire chaque changement. Elle est déployée dans deux régions, pour que l’application reste accessible si l’une des deux tombe. La connexion des partenaires passe par une double authentification, et le prestataire cloud d’Ochre Bio surveille l’application 24 heures sur 24, avec des alarmes et des procédures préparées avec lui.
La difficulté : douze heures pour chaque mise à jour des données
Les scientifiques d’Ochre Bio livrent régulièrement une nouvelle version des données d’OBELiX, sous forme de fichiers. Au départ, chaque version devait être chargée dans une base de données avant que les graphiques soient recalculés. Ce chargement durait au moins douze heures, et une erreur repérée ensuite dans les données obligeait à tout reprendre.
Ce délai est devenu un problème à quelques jours de l’ouverture au premier partenaire, alors que les données devaient encore être mises à jour, et les graphiques avec elles. À douze heures par essai, il restait la place pour très peu de corrections, sur des données que le partenaire allait consulter dès le premier jour.
On a donc supprimé l’étape du chargement. Les tâches de calcul lisent directement les fichiers livrés par les scientifiques, au format Parquet, avec DuckDB. Le changement fonctionnait dès le lendemain de sa proposition. Il a servi quelques jours plus tard, quand deux erreurs ont été trouvées dans les données : chacune a été corrigée et vérifiée en quelques minutes. Cette lecture directe est restée le fonctionnement d’OBELiX.
Les résultats
OBELiX est passée d’un outil interne à une plateforme que des laboratoires partenaires consultent. Elle est en production depuis juillet 2024, et Ochre Bio l’a ouverte aux équipes de son premier partenaire le même mois. Six mois plus tard, un second partenaire avait sa propre version, avec sa page d’accueil et ses droits d’accès.
Ochre Bio a ensuite repris la maintenance en interne, avec un développeur dont on a accompagné l’arrivée. On a laissé dans le dépôt la documentation et les procédures des opérations courantes, comme régler les droits d’un groupe ou relancer le calcul après une mise à jour des données, et notre mission s’est terminée trois mois après son arrivée.
La transmission a tenu. Plus d’un an après, l’équipe d’Ochre Bio nous confirmait que l’application tournait toujours, sans changement majeur, avec beaucoup plus de données qu’à notre départ.
Vous avez une application Shiny interne à ouvrir à des clients ou à des partenaires ? Écrivez-nous.
Commentaires