Qu’est-ce qui se passe quand l’IA commence à réécrire les outils sur lesquels la bioinformatique s’appuie ?
Le mois dernier, des membres du C3G et de l’équipe HeDS‑D2R sont allés à la conférence Canadian Bioinformatics Hub (CBHC) 2026, qui s’est tenue sur trois jours au MaRS Discovery District à Toronto [1]. L’événement a réuni la communauté de recherche de partout au Canada et, comme bien des conférences cette année, il a été fortement marqué par le sujet de l’intelligence artificielle (IA).
Parmi les participants se trouvait Senthilkumar Kailasam (PhD), ancien du C3G et présentement analyste scientifique de données chez HeDS‑D2R. En repensant aux discussions du CBHC, Senthil a été frappé non seulement par la vitesse à laquelle l’IA accélère le développement de nouveaux outils en bioinformatique, mais aussi par un changement plus discret : son rôle croissant dans la réécriture des outils déjà utilisés dans le domaine. Dans le texte qui suit, Senthilkumar explore cette tendance émergente et ses implications.
Senthilkumar Kailasam réfléchit à l’IA au CBHC 2026
Au CBHC cette année, il était impossible d’ignorer l’attrait exercé par l’IA sur les conférences plénières, les tables rondes et même un petit (mais croissant) nombre de résumés présentant des agents d’IA en bioinformatique.
Hamed D. Najafabadi (PhD), professeur agrégé en génétique humaine à l’Université McGill, et Benjamin Haibe‑Kains (PhD), chercheur principal au Princess Margaret Cancer Centre de l’Université de Toronto, ont animé une discussion informelle avec l’un des meilleurs titres du programme :
« A-t-on vraiment besoin d’un autre outil de bioinformatique ? À construire ou ne pas construire ? ».
C’est exactement la bonne question. Mais il y en a une autre, plus discrète, juste derrière, et c’est celle qui m’est restée en tête :
« Comment réécrire les outils qu’on a déjà, de façon efficace et responsable, avec l’IA ? »
Parce qu’il y a un point que personne n’a vraiment mis sur une diapo : pendant qu’on débat de la création de nouveaux outils, des agents de programmation basés sur l’IA sont déjà en train de réécrire silencieusement les anciens (comme samtools, fastqc et une bonne partie de nf-core), dans des langages que la plupart des gens dans la salle n’ont jamais compilés.
« Construire ou ne pas construire » suppose qu’on part d’une feuille blanche. La vague de réécriture, elle, ne part pas de zéro. Elle part d’un code C++ vieux de 20 ans… avec une simple consigne : « porte ça en Rust ».
Mélanie Courtot, directrice principale de l’informatique génomique à l’Ontario Institute for Cancer Research, a donné une présentation qui mettait bien en lumière une réalité connexe : le potentiel de l’IA repose sur des données propres, structurées et interopérables. Investir dans ces bases est essentiel pour que l’IA tienne ses promesses.
La même logique s’applique à un niveau plus bas : une réécriture rapide repose sur la justesse, qui est tout aussi essentielle.
L’écosystème Rust est déjà bien établi
L’écosystème Rust en bio-informatique ne cesse de croître, et plusieurs outils sont déjà largement utilisés dans les workflows quotidiens, notamment :
- rust-htslib (liaisons BAM/VCF/CRAM/HTS)
- perbase (métriques par base)
- pymol_rs (visualisation de structures)
- sourmash (empreintes et recherche de similarité)
- varlociraptor (appel de variants)
- alevin-fry et salmon 2.0 (cellules uniques et quantification des transcrits)
- RustQC (contrôle qualité du séquençage)
La question n’est plus de savoir si Rust peut offrir de la performance. C’est clairement oui. La vraie difficulté, c’est : qu’est-ce qu’il faut pour qu’une réécriture inspire le même niveau de confiance que l’outil original ?
Ce que disent certains sceptiques
Dans le balado OMGenomics, l’animateur Robert Aboukhalil (PhD) affirme que réécrire un logiciel est presque toujours une mauvaise idée, sauf dans de rares cas [2].
L’argument est simple : les outils établis accumulent des années de cas particuliers. Chaque fichier FASTQ étrange issu d’un séquenceur en fin de vie, chaque solution bricolée dont quelqu’un dépendait, tout ça finit par être intégré dans le code. Même si ce code a été écrit par des étudiants, il fait aujourd’hui tourner des milliers d’analyses critiques.
Le principal risque, ce ne sont pas les plantages (généralement détectés rapidement), mais plutôt un code qui produit des résultats erronés en toute confiance.
Conventions de nommage
Ajouter un suffixe « _rs » peut faciliter l’identification des réécritures en Rust, mais ça peut aussi involontairement emprunter la réputation de l’outil original.
Une règle simple peut aider :
- Si le nom se réfère à un algorithme général (comme bwa ou minimap2), ajouter « _rs » est généralement acceptable.
- Si le nom correspond à un outil distinct et reconnu (comme Salmon ou Kraken), il vaut mieux choisir un nouveau nom et mentionner clairement l’original dans le README.
Ainsi, on reconnaît l’héritage sans donner l’impression de profiter de la réputation d’un autre projet.
Quand une réécriture est justifiée
Les critères suivants reviennent constamment : ne réécrire que lorsqu’on comprend suffisamment bien l’original pour distinguer un compromis essentiel d’un choix accessoire.
Salmon 2.0 est un bon exemple concret de cette approche :
Il s’agit d’une réécriture complète en Rust par COMBINE‑lab (les auteurs originaux), et son guide de migration montre le niveau de rigueur attendu [3] :
- La sortie quant.sf reste inchangée ;
- Le nouveau format d’index refuse les anciens index avec un message d’erreur clair, plutôt que de produire des résultats erronés ;
- Une concordance par transcrit avec la version C++ d’environ 0,999 est rapportée, avec des options précises documentées pour reproduire les anciens comptages d’alignement ;
- Et les suppressions (p. ex. salmon alevin → alevin-fry) sont explicites plutôt que silencieuses.
C’est ce type de démarche que les sceptiques ont tendance à approuver : des réécritures faites par les personnes qui savent exactement quelles parties du code original sont essentielles. C’est la même approche qu’a adoptée Felix Krüger en réécrivant Trim Galore en Rust [4].
Principes communs : rewrites.bio
Seqera (l’équipe derrière Nextflow) a transformé ces préoccupations en une sorte de manifeste [5]. À haut niveau, le message est simple :
- Donner le crédit aux auteurs originaux
- Reproduire fidèlement (un résultat « amélioré » devient en fait un autre outil)
- Être transparent sur l’usage de l’IA et sur la façon dont ça a été validé
- Voir grand, mais valider une fonction à la fois
- Faire des benchmarks sur des données réelles et des cas limites
- Ne construire que ce qui est nécessaire et échouer de manière explicite sinon
- Figer les versions et documenter la correspondance des résultats
L’attrait est évident. Par exemple, un pipeline de QC RNA-seq basé sur Rust (RustQC) a rapporté être environ 63 fois plus rapide que la pile traditionnelle sur un fichier BAM de 10 Go, ce qui représenterait une économie d’environ 1,5 million d’heures CPU et près de 150 tonnes de CO₂e par année à 100 000 échantillons [6].
Questions à se poser
Une question résume bien le débat :
Comment savoir si votre réécriture est correcte, et pourriez-vous le prouver à un sceptique ?
« Ça compile » ou « le badge est vert » restent des suppositions confiantes, pas une validation.
Voici quelques questions essentielles :
- Comprenez-vous vraiment le comportement clé de l’outil original ?
- Avez-vous testé avec des données réelles, incluant des cas difficiles ?
- Le nom que vous avez choisi aide-t-il les utilisateurs ou emprunte-t-il une réputation ?
- Avez-vous reconnu le travail des auteurs originaux ?
Écrire en Rust, c’est la partie facile. La validation a toujours été, et restera, la partie difficile.
Ce que cela signifie pour le C3G
Du point de vue du C3G, l’essor des outils d’IA vient renforcer une priorité déjà bien établie : choisir des outils qui améliorent l’efficacité, tant en temps qu’en ressources de calcul, et bâtir des workflows plus robustes et fiables.
Cependant, avec la multiplication des outils réécrits, surtout ceux générés entièrement ou en partie par l’IA, un niveau de prudence supplémentaire s’impose.
Toutes les réécritures ne reproduisent pas fidèlement le comportement des outils d’origine, même lorsqu’elles promettent des gains de performance importants. Il en va de même pour les pipelines conçus avec des agents d’IA : ils peuvent proposer des alternatives plus rapides ou plus modernes, mais celles-ci reposent souvent sur des outils récemment réécrits, dont les algorithmes ne correspondent pas toujours parfaitement aux originaux.
Dans ce contexte, la validation rigoureuse et des choix d’outils éclairés sont tout aussi importants que la performance.
Références
- Canadian Bioinformatics Hub Conference (CBHC) 2026, Bioinformatics.ca. MaRS, Toronto, 27–29 May 2026. https://bioinformatics.ca
- Aboukhalil, R. & Nattestad, M. Software rewrites. OMGenomics Podcast. https://youtu.be/0o2XnEBDxrI
- COMBINE-lab. Migrating from C++ salmon (≤ 1.12.0) to salmon 2.0 (Rust). salmon repository, MIGRATION.md. https://github.com/COMBINE-lab/salmon/blob/master/MIGRATION.md
- Krueger, F. Trim Galore v2 — a Rust rewrite of the original Perl tool. https://github.com/FelixKrueger/TrimGalore
- rewrites.bio — Principles for rewriting bioinformatics tools with AI. https://rewrites.bio
- Seqera Labs. RustQC — benchmark details. https://seqeralabs.github.io/RustQC/rna/benchmark-details/
