Un séquenceur d’ADN moderne ne produit pas un résultat. Il produit un fichier texte de plusieurs millions de lignes, où chaque ligne est un fragment de séquence accompagné d’un score de qualité. Personne ne l’ouvre. Personne ne le lit. Il n’existe aucun logiciel grand public capable d’en afficher le contenu de façon utile, et un tableur refuse simplement de le charger.
C’est le point de départ de la bio-informatique, et c’est aussi ce qui m’a amené à écrire cet article. Je viens de l’infrastructure : réseaux, systèmes, sécurité. Je découvre ce domaine depuis l’autre bout, celui des machines qui font tourner les analyses plutôt que celui des analyses elles-mêmes. Et ce que j’y trouve ressemble beaucoup plus à de l’administration système qu’à de la biologie.
Note de méthode. Je n’ai pas encore travaillé dans un laboratoire de bio-informatique. Tout ce qui suit est reconstitué à partir de la documentation des outils, des spécifications de formats et des guides d’utilisation des infrastructures de calcul. Les extraits de code sont des exemples tirés de ces sources, pas des retours d’expérience. Ils sont en revanche vérifiables : n’importe qui peut les rejouer sur des fichiers publics, et c’est ce que je recommande de faire plutôt que de me croire sur parole.
L’informatique n’est plus un support de la recherche#
On présente encore souvent l’informatique comme un outil de la recherche, au même titre qu’un microscope ou une centrifugeuse. La comparaison est trompeuse. Dans une grande partie des sciences du vivant contemporaines, le traitement informatique n’accompagne pas l’expérience : il est une partie de l’expérience. Trois raisons à cela.
Le volume a dépassé l’échelle humaine#
Une expérience de séquençage produit couramment plusieurs dizaines de gigaoctets de données brutes, et un projet complet peut se compter en téraoctets. À cette échelle, la notion d’inspection manuelle disparaît. On ne « regarde » pas les données ; on écrit un programme qui les regarde à notre place et qui rapporte ce qu’il a trouvé.
Le changement est plus profond qu’une simple question de quantité. Quand un chercheur ne peut plus voir ses données directement, la qualité de son résultat dépend entièrement de la qualité du code qui les a traitées. Une erreur de filtrage ne se voit pas : elle produit un résultat plausible et faux.
La reproductibilité impose le script#
Un résultat scientifique doit pouvoir être reproduit par quelqu’un d’autre. Cette exigence, qui est au fondement de la méthode expérimentale, a une conséquence directe et rarement énoncée : le traitement des données doit être un script, pas une suite de clics.
Une manipulation faite à la souris dans une interface graphique ne laisse aucune trace exploitable. On ne peut ni la relire, ni la corriger, ni la relancer à l’identique deux ans plus tard, ni la transmettre à un collègue autrement qu’en lui décrivant les gestes. Un script, lui, est un document : il dit exactement ce qui a été fait, dans quel ordre, avec quelles versions. C’est pour cette raison que la ligne de commande domine dans la recherche, et non par conservatisme.
C’est aussi pour cette raison que les dépôts de code se sont installés au cœur de la publication scientifique. De plus en plus de revues demandent le code d’analyse en même temps que l’article.
Ce qui est fait une fois doit tourner mille fois#
Le dernier facteur est le plus banal et le plus déterminant. Une analyse mise au point sur un échantillon doit ensuite être appliquée à l’ensemble de la cohorte. Cent échantillons, mille, parfois davantage. Personne ne refait cent fois la même série de manipulations à la main.
C’est exactement le problème que résout l’automatisation, et c’est un terrain familier pour quiconque vient de l’administration système. Un pipeline d’analyse génomique et un script de déploiement posent les mêmes questions : comment enchaîner des étapes, que faire quand l’une échoue, comment reprendre sans tout recommencer, comment savoir ce qui a réellement tourné.
Ce qui tourne réellement dans un laboratoire#
Voilà pour le pourquoi. Reste la question qui m’intéressait le plus en abordant ce domaine : sur quoi ça tourne, concrètement.
Du Linux, presque partout#
La réponse courte est : du Linux. La totalité des superordinateurs du TOP500 fonctionnent sous Linux, et les serveurs de calcul des laboratoires suivent la même logique, à plus petite échelle.
Ce n’est pas un choix idéologique. Les outils de bio-informatique sont majoritairement issus du monde académique et distribués sous forme de code source à compiler. Ils supposent un environnement POSIX, des bibliothèques système standard, une chaîne de compilation GCC. Vingt-cinq ans d’outillage se sont accumulés sur ces bases, et personne n’a jamais eu de raison de tout réécrire ailleurs. À cela s’ajoute la question du coût : multiplier des licences par plusieurs centaines de nœuds de calcul n’a aucun sens pour un budget de recherche.
On ne travaille pas sur sa propre machine#
Le poste de travail du chercheur sert à écrire du code et à regarder des résultats. Le calcul, lui, se fait ailleurs, sur une grappe de serveurs partagée entre plusieurs équipes. Au Québec, ces infrastructures sont notamment fournies par l’Alliance de recherche numérique du Canada et Calcul Québec.
L’accès se fait par SSH. On se connecte à un nœud de connexion, on y dépose ses données et son code, et on repart. Cette organisation a une conséquence pratique immédiate : tout le travail se fait dans un terminal, sur une machine distante, souvent à travers une session qu’il faut pouvoir laisser tourner sans y être connecté. D’où l’omniprésence de tmux et screen, qui permettent de détacher une session et de la retrouver intacte le lendemain.
On ne lance pas une commande, on soumet un travail#
C’est le point le plus déroutant quand on découvre ces environnements par la documentation. Sur une grappe partagée, on n’exécute pas directement son analyse. On la décrit dans un fichier — quelles ressources il faut, combien de cœurs, combien de mémoire, pour combien de temps — et on la soumet à un ordonnanceur, le plus souvent SLURM.
Les guides d’utilisation des grappes de calcul donnent tous des scripts de soumission bâtis sur le même modèle :
#!/bin/bash
#SBATCH --job-name=alignement
#SBATCH --cpus-per-task=8
#SBATCH --mem=32G
#SBATCH --time=04:00:00
module load samtools
samtools sort -@ 8 echantillon.bam -o echantillon_trie.bamOn soumet avec sbatch mon_script.sh, on consulte l’état de la file avec squeue. Et on attend son tour.
Pour quelqu’un habitué à lancer une commande et à voir le résultat défiler, c’est un changement de rythme. Mais la logique est celle de n’importe quel système de files d’attente : arbitrer entre plusieurs utilisateurs pour une ressource limitée, avec des priorités et des quotas.
Le problème des versions, et comment il est résolu#
Un dernier élément mérite d’être mentionné, parce qu’il touche directement à la reproductibilité évoquée plus haut. Une analyse ne dépend pas seulement de son code, mais aussi de la version exacte de chaque outil utilisé. Deux versions d’un même aligneur ne produisent pas nécessairement des résultats identiques.
Trois mécanismes cohabitent pour gérer cela :
- Les modules d’environnement (
module load), qui permettent de charger une version précise d’un logiciel installé par l’administrateur de la grappe. - Conda, et son implémentation plus rapide mamba, qui permettent à chaque utilisateur de créer ses propres environnements isolés sans droits d’administration. Le canal Bioconda distribue par ce biais des milliers d’outils du domaine.
- Les conteneurs, qui figent l’ensemble de l’environnement logiciel. En milieu partagé, on utilise généralement Apptainer plutôt que Docker : ce dernier suppose un démon privilégié, ce qui est inacceptable sur une machine multi-utilisateurs.
Au-dessus de tout cela, des gestionnaires de flux de travaux comme Nextflow ou Snakemake orchestrent les étapes, gèrent les dépendances entre elles et permettent de reprendre un traitement interrompu là où il s’était arrêté.
Pourquoi les biologistes utilisent grep#
Reste la partie la plus concrète, et celle qui explique pourquoi un profil Linux n’est pas dépaysé dans ce domaine : les formats de données de la bio-informatique sont du texte brut.
Ce n’est pas un accident historique dont on n’aurait pas su se débarrasser. C’est un choix qui a été maintenu délibérément, parce qu’il rend l’ensemble de l’outillage Unix immédiatement applicable. Un format binaire propriétaire aurait exigé un logiciel dédié pour chaque opération. Un format texte se laisse filtrer, compter, trier et découper avec des outils qui existaient déjà.
Les commandes qui suivent sont construites à partir des spécifications publiques de ces formats. Elles ne demandent aucun outil spécialisé : grep, awk et cut suffisent, ce qui est précisément ce que je cherche à illustrer.
FASTA : compter des séquences#
Le format FASTA stocke des séquences. Chaque séquence commence par une ligne d’en-tête débutant par >, suivie de la séquence elle-même sur une ou plusieurs lignes.
>seq1 description de la première séquence
ATGCGATCGATCGATCGTAGCTAGCTAGCTAGC
>seq2 description de la deuxième
GGCTAACGTAACGTAACGTAACGTAACGTAACGCompter le nombre de séquences d’un fichier revient donc à compter les lignes d’en-tête :
grep -c "^>" genome.fastaExtraire uniquement la liste des identifiants :
grep "^>" genome.fasta | cut -d' ' -f1 | tr -d '>'FASTQ : le piège du comptage naïf#
Le format FASTQ ajoute un score de qualité pour chaque base. Chaque enregistrement occupe exactement quatre lignes : l’identifiant, la séquence, une ligne de séparation, et les scores.
La tentation est de compter les lignes commençant par @, qui est le caractère d’en-tête. C’est une erreur classique : la ligne de qualité peut elle aussi commencer par @, ce caractère faisant partie de l’échelle d’encodage des scores. Le comptage correct passe par la structure du fichier :
echo $(( $(wc -l < lecture.fastq) / 4 ))Cet exemple illustre bien la nature du travail : il ne suffit pas de connaître les commandes, il faut connaître le format sur lequel on les applique.
VCF : filtrer des variants#
Un fichier VCF liste des variations génétiques. C’est un tableau séparé par des tabulations, précédé de lignes d’en-tête commençant par #. La première colonne est le chromosome, la deuxième la position.
Compter les variants d’un chromosome donné :
awk '$1 == "chr7"' variants.vcf | wc -lExtraire ceux d’une région précise :
awk -F'\t' '$1 == "chr7" && $2 >= 100000 && $2 <= 200000' variants.vcfCompter les variants par chromosome, triés par fréquence :
grep -v "^#" variants.vcf | cut -f1 | sort | uniq -c | sort -rnCette dernière ligne n’a rien de spécifique à la génomique. C’est l’enchaînement cut | sort | uniq -c | sort -rn que tout administrateur système utilise pour dépouiller un journal Apache. Appliqué à un fichier de variants, il répond à une question biologique.
Ce que j’en retiens#
En abordant la bio-informatique par l’infrastructure, on découvre un domaine dont les problèmes techniques sont largement familiers : gestion de versions, isolation des environnements, ordonnancement de tâches, stockage partagé, traitement de gros volumes de texte. Ce qui change, ce n’est pas l’outillage, c’est la nature des questions auxquelles il sert à répondre.
C’est probablement la raison pour laquelle ces équipes recrutent difficilement. Le profil recherché n’est ni un biologiste qui bricole un peu, ni un informaticien indifférent au contenu des données. Il se situe entre les deux, et il se forme mal dans les cursus existants.
Je ne prétends pas encore m’y situer. Mais l’entrée par le système, elle, est ouverte.
Le prochain article portera sur l’éco-informatique : le même type de traitement appliqué aux données de biodiversité — ADN environnemental, métabarcoding, données d’occurrence d’espèces.
