flowchart TD FQ["FASTQ<br/>reads de séquençage bruts"] BAM["SAM / BAM<br/>reads alignés sur le génome"] COUNTS["Matrice de comptage<br/>reads par gène"] VCF["VCF<br/>variants génétiques"] ANNO["GTF / GFF · BED<br/>annotation des gènes & intervalles"] FQ -->|aligner| BAM BAM -->|quantifier| COUNTS BAM -->|appeler les variants| VCF ANNO -. "là où sont les gènes" .-> COUNTS ANNO -. "régions d'intérêt" .-> VCF
Les formats de fichiers en bioinformatique : FASTQ, SAM/BAM, VCF, GTF/GFF & BED expliqués
Reconnaissez les fichiers dans lesquels arrivent les données omiques, sachez ce que chacun stocke, lisez ses colonnes — et évitez le piège des coordonnées à base 0 ou à base 1 qui décale silencieusement chaque résultat
Une référence pratique des principaux formats de fichiers bioinformatiques qu’un data scientist reçoit : FASTQ (reads bruts), SAM/BAM (alignements), VCF (variants), GTF/GFF (annotation des gènes) et BED (intervalles génomiques). Pour chacun, apprenez ce qu’il stocke, ce que signifient ses colonnes clés, et comment le lire — plus le piège le plus important de tous : BED est à base 0 et semi-ouvert tandis que GTF/GFF, SAM et VCF sont à base 1, un décalage d’une unité qui ruine les coordonnées si vous le manquez.
AstucePoints clés
- Les vraies données omiques arrivent sous forme de fichiers aux extensions cryptiques —
.fastq.gz,.bam,.vcf,.gtf,.bed. Chacun occupe une étape connue du pipeline : FASTQ (reads bruts) → SAM/BAM (alignements) → comptages ; plus VCF (variants), GTF/GFF (annotation des gènes) et BED (intervalles). - Un enregistrement FASTQ fait 4 lignes : identifiant, séquence,
+, et une chaîne de qualité Phred par base (un caractère de qualité par base — elles doivent avoir la même longueur). - SAM est un texte d’alignement délimité par des tabulations, lisible par l’humain ; BAM est les mêmes données compressées en binaire — ne faites jamais
catsur un BAM, visualisez-le avecsamtools view. - VCF stocke des variants (8 colonnes fixes :
CHROM POS ID REF ALT QUAL FILTER INFO) ; GTF/GFF stocke des modèles de gènes (9 colonnes se terminant par un champattributesen texte libre) ; BED stocke de simples intervalles génomiques. - Le piège qui attrape tout le monde : BED est à base 0, semi-ouvert ; GTF/GFF, SAM et VCF sont à base 1. Mélangez-les et chaque coordonnée est décalée d’une unité — silencieusement.
Introduction
On vous a remis un dossier de données de séquençage en vous demandant de « simplement le charger ». À l’intérieur, des fichiers se terminant par .fastq.gz, .bam, .vcf, .gtf, .bed — et aucun ne s’ouvre proprement dans un tableur. Avant toute analyse, vous devez savoir ce que contient chaque fichier, où il se situe dans le pipeline, et comment en lire les colonnes. Cette reconnaissance est tout l’objet de cette leçon.
Ces formats ne sont pas arbitraires. Ils correspondent aux étapes que traversent les données : le séquenceur émet des reads bruts (FASTQ), un aligneur place ces reads sur le génome (SAM/BAM), et les outils en aval transforment les alignements en comptages de reads par gène, ou en variants (VCF). Deux autres formats décrivent le génome lui-même plutôt que votre échantillon : GTF/GFF indique où sont les gènes, et BED marque des intervalles arbitraires. Apprenez à reconnaître les cinq et vous pourrez vous asseoir devant n’importe quel projet omique en sachant ce que vous regardez.
Où se situe chaque format dans le pipeline
Le workflow de séquençage de base est une courte chaîne — les reads, puis les alignements, puis soit des comptages d’expression, soit des appels de variants — avec les formats d’annotation qui s’y greffent sur le côté pour indiquer aux outils où sont les gènes :
Prenons maintenant les cinq formats un par un.
FASTQ — reads de séquençage bruts
Un fichier FASTQ est ce qui sort du séquenceur : des millions de courts reads, chacun une chaîne de bases plus un score de qualité pour chaque base. C’est du texte brut, presque toujours compressé en gzip (.fastq.gz). Chaque read fait exactement quatre lignes :
| Ligne | Commence par | Contenu |
|---|---|---|
| 1 | @ |
Identifiant du read (instrument, run, coordonnées) |
| 2 | — | La séquence — les bases A/C/G/T/N |
| 3 | + |
Séparateur (répète éventuellement l’identifiant de la ligne 1) |
| 4 | — | Qualité Phred — un caractère ASCII par base |
Ce ne sont vraiment que quatre lignes de texte. Lisez un enregistrement avec R base et la structure devient évidente :
record <- c(
"@SEQ_ID_001", # 1. identifier (starts with @)
"GATTTGGGGTTCAAAGCAGTATCGATCA", # 2. the read sequence
"+", # 3. separator
"IIIIIIIIIIIIIII9999IIIG+++!!" # 4. one quality character per base
)
record[1] "@SEQ_ID_001" "GATTTGGGGTTCAAAGCAGTATCGATCA"
[3] "+" "IIIIIIIIIIIIIII9999IIIG+++!!"# The sequence and the quality string must be the SAME length:
c(seq = nchar(record[2]), qual = nchar(record[4])) seq qual
28 28 Vingt-huit bases, vingt-huit caractères de qualité — ils correspondent un à un. Cette égalité est le contrôle de cohérence : si la ligne 2 et la ligne 4 diffèrent en longueur, l’enregistrement est corrompu.
La qualité Phred, décodée
La ligne 4 ressemble à du charabia, mais chaque caractère encode un score de qualité Phred = le code ASCII du caractère moins 33 (l’encodage « Phred+33 »). Un score plus élevé signifie que le logiciel d’appel de bases était plus sûr de lui. Décodez-la en une ligne :
# First six bases vs the worst base in our read:
utf8ToInt(substr("IIIIIIIIIIIIIII9999IIIG+++!!", 1, 6)) - 33 # the 'I' run[1] 40 40 40 40 40 40utf8ToInt("!") - 33 # the '!' character[1] 0I se décode en 40 (une chance d’erreur sur 10 000 — excellent) ; ! se décode en 0 (le plus bas possible — le logiciel n’avait aucune confiance). Ce read commence donc fort et se dégrade en bruit à l’extrémité 3′, la chute de qualité classique que vous rognez avant l’alignement. Les vrais outils analysent le FASTQ pour vous :
# Conceptual — the real parser (not run here):
library(ShortRead)
fq <- readFastq("reads.fastq.gz")
sread(fq) # the sequences
quality(fq) # the Phred qualitiesSAM/BAM — reads alignés
Une fois qu’un aligneur (BWA, Bowtie2, STAR) a placé chaque read sur le génome, le résultat est un fichier SAM : du texte délimité par des tabulations avec une ligne par read aligné. BAM est exactement la même information compressée en binaire — plus petite et indexable, mais non lisible par l’humain. Vous passez de l’un à l’autre avec samtools ; les outils en aval veulent presque toujours le BAM.
Chaque ligne d’alignement comporte 11 colonnes obligatoires. Celles que vous lisez réellement :
| Colonne | Nom | Signification |
|---|---|---|
| 1 | QNAME |
Nom du read (correspond à l’identifiant FASTQ) |
| 2 | FLAG |
Drapeaux binaires (pairé ? aligné ? brin inverse ? doublon ?) |
| 3 | RNAME |
Nom de la référence sur laquelle le read s’est aligné (ex. chr1) |
| 4 | POS |
Position d’alignement la plus à gauche — à base 1 |
| 5 | MAPQ |
Qualité d’alignement (confiance dans la position, échelle Phred) |
| 6 | CIGAR |
Chaîne compacte de correspondances/insertions/délétions (ex. 28M, 5S23M) |
| 10 | SEQ |
La séquence du read |
| 11 | QUAL |
Qualité Phred par base (comme dans FASTQ) |
(Les colonnes 7–9 ignorées — RNEXT, PNEXT, TLEN — donnent la référence, la position et la longueur de template du read apparié pour les reads paired-end ; vous les lisez rarement à la main.)
POS est à base 1 — la première base d’un chromosome est la position 1, pas 0 (retenez-le ; c’est la moitié du piège des coordonnées ci-dessous). Pour lire un BAM en R, vous utilisez Rsamtools, pas readLines :
# Conceptual — BAM is binary; use the parser, never cat/readLines:
library(Rsamtools)
bam <- scanBam("aligned.bam")[[1]]
bam$pos # 1-based leftmost positions
bam$cigar # the CIGAR stringsVCF — variants
Un fichier VCF (Variant Call Format) liste les positions où le génome de votre échantillon diffère de la référence — SNP, insertions, délétions. Après un bloc d’en-tête préfixé par ##, il est délimité par des tabulations avec 8 colonnes fixes, puis des colonnes de génotype par échantillon :
| Colonne | Nom | Signification |
|---|---|---|
| 1 | CHROM |
Chromosome |
| 2 | POS |
Position du variant — à base 1 |
| 3 | ID |
Identifiant du variant (ex. un rsID, ou . s’il n’y en a pas) |
| 4 | REF |
Allèle de référence (la base dans le génome) |
| 5 | ALT |
Allèle alternatif (celui de votre échantillon) |
| 6 | QUAL |
Confiance dans l’appel, échelle Phred |
| 7 | FILTER |
PASS, ou la raison du filtrage de l’appel |
| 8 | INFO |
Annotations séparées par des points-virgules (profondeur, fréquence allélique, …) |
Deux colonnes suivent généralement : FORMAT (ce que signifie chaque champ de génotype, ex. GT:DP) et une colonne par échantillon contenant le génotype de cet échantillon (0/1 = hétérozygote, 1/1 = homozygote alternatif). Comme pour SAM, POS est à base 1. Lisez-en un avec VariantAnnotation :
# Conceptual — the real parser (not run here):
library(VariantAnnotation)
vcf <- readVcf("variants.vcf.gz", "hg38")
rowRanges(vcf) # CHROM/POS as a GRanges
ref(vcf); alt(vcf)GTF/GFF — annotation des gènes
GTF (Gene Transfer Format) et GFF (General Feature Format) décrivent où sont les gènes sur le génome — la carte qu’un aligneur ou un outil de comptage utilise pour décider à quel gène appartient un read. Les deux sont délimités par des tabulations avec 9 colonnes :
| Colonne | Nom | Signification |
|---|---|---|
| 1 | seqname |
Chromosome / contig |
| 2 | source |
Qui a produit l’annotation (ex. ensembl) |
| 3 | feature |
gene, transcript, exon, CDS, … |
| 4 | start |
Début de l’élément — à base 1 |
| 5 | end |
Fin de l’élément — inclusive |
| 6 | score |
Score, ou . |
| 7 | strand |
+ ou - |
| 8 | frame |
Cadre de lecture pour les éléments codants, ou . (GFF3 nomme cette colonne phase) |
| 9 | attribute |
Paires clé/valeur en texte libre (gene_id, gene_name, …) |
Le nom complet du gène et son identifiant vivent dans cette dernière colonne attribute. GTF sépare les paires par key "value"; ; GFF3 utilise key=value;. Découpez une chaîne d’attributs GTF avec R base :
attr <- 'gene_id "ENSG00000012048"; gene_name "BRCA1"; gene_biotype "protein_coding";'
fields <- strsplit(attr, ";\\s*")[[1]]
fields[fields != ""][1] "gene_id \"ENSG00000012048\"" "gene_name \"BRCA1\""
[3] "gene_biotype \"protein_coding\""Chaque paire devient un élément — c’est ainsi qu’un parseur extrait gene_name "BRCA1" de la ligne.
Note
GTF vs GFF — quelle différence ? Mêmes 9 colonnes ; seule la syntaxe des attributs de la colonne 9 diffère. GTF utilise gene_id "X"; transcript_id "Y"; (espace, guillemets, points-virgules). GFF3 utilise ID=gene:X;Name=BRCA1; (signes =, sans guillemets) et ajoute une clé Parent= pour imbriquer les exons sous les transcrits sous les gènes. Les outils de comptage (featureCounts, HTSeq) attendent généralement du GTF.
Le vrai chargeur construit une base de données de transcrits plutôt que de vous faire analyser le texte vous-même :
# Conceptual — the real parser (not run here):
library(rtracklayer)
anno <- import("annotation.gtf") # a GRanges of features
library(txdbmaker)
txdb <- makeTxDbFromGFF("annotation.gtf") # a queryable transcript databaseBED — intervalles génomiques
Un fichier BED est le plus simple de tous : de simples intervalles génomiques, un par ligne, utilisés pour les pics, les régions d’intérêt, les cibles d’amorces — tout ce que vous marquez sur le génome. Seules les trois premières colonnes sont obligatoires :
| Colonne | Nom | Obligatoire ? | Signification |
|---|---|---|---|
| 1 | chrom |
oui | Chromosome |
| 2 | chromStart |
oui | Début — à base 0 |
| 3 | chromEnd |
oui | Fin — exclusive (semi-ouverte) |
| 4 | name |
optionnel | Nom de l’élément |
| 5 | score |
optionnel | Score (0–1000) |
| 6 | strand |
optionnel | + ou - |
Remarquez les colonnes 2–3 : BED utilise un système de coordonnées à base 0, semi-ouvert — la convention inverse de tous les formats ci-dessus. Cette différence est le bug silencieux le plus courant en génomique, elle a donc droit à sa propre section.
# Conceptual — the real parser (not run here):
library(rtracklayer)
peaks <- import("peaks.bed") # a GRanges; rtracklayer converts BED's
# 0-based coordinates to R's 1-based GRanges for youLe piège du système de coordonnées (à lire deux fois)
Voici le piège qui ruine plus d’analyses que n’importe quelle erreur d’analyse syntaxique :
BED est à base 0 et semi-ouvert. GTF/GFF, SAM et VCF sont à base 1 et inclusifs.
Dans un système à base 1 (GTF/GFF, SAM, VCF), la première base d’un chromosome est la position 1, et la coordonnée de fin est incluse dans l’élément. Dans un système à base 0, semi-ouvert (BED), le décompte commence à 0, et la coordonnée de fin n’est pas incluse — elle pointe juste après la dernière base. Conséquence : la même portion physique d’ADN s’écrit avec des nombres différents selon le format.
Prenez les cinq premières bases d’un chromosome. En GTF/GFF, c’est start = 1, end = 5. En BED, c’est chromStart = 0, chromEnd = 5. Les deux décrivent le même élément de 5 pb — et l’arithmétique de longueur diffère dans chaque système :
# Same 5-bp feature, written in two coordinate systems:
gtf_len <- 5 - 1 + 1 # GTF/GFF (1-based, inclusive): end - start + 1
bed_len <- 5 - 0 # BED (0-based, half-open): end - start
c(GTF = gtf_len, BED = bed_len)GTF BED
5 5 Les deux donnent 5 — mais seulement parce que vous avez utilisé la bonne formule pour chacun. Soustrayez à la manière BED sur des coordonnées GTF (ou oubliez le + 1) et chaque longueur et chevauchement est décalé d’une unité. Les règles pratiques :
- Convertir
startGTF/VCF/SAM →startBED : soustrayez 1. La fin reste identique. - Convertir
startBED →startà base 1 : ajoutez 1. La fin reste identique. - En R, laissez les outils le faire :
rtracklayer::import()etGenomicRangesutilisent en interne des coordonnées à base 1 et convertissent le BED pour vous à l’import — vous raisonnez ainsi dans un seul système sans éditer les nombres à la main.
| Format | Système de coordonnées | Première base | Coordonnée de fin |
|---|---|---|---|
| FASTQ | (aucune coordonnée) | — | — |
SAM/BAM (POS) |
à base 1 | 1 | — |
VCF (POS) |
à base 1 | 1 | inclusive |
GTF/GFF (start/end) |
à base 1 | 1 | inclusive |
BED (chromStart/chromEnd) |
à base 0, semi-ouvert | 0 | exclusive |
Dans le doute, écrivez les coordonnées d’un élément connu des deux façons et vérifiez que la longueur est celle attendue — le calcul de deux lignes ci-dessus est plus rapide que de déboguer un résultat décalé en aval.
Problèmes fréquents
Décalage d’une unité entre BED et tout le reste. Une région paraît décalée d’une base, ou un chevauchement qui devrait correspondre revient vide. La cause est presque toujours le mélange de coordonnées BED à base 0 avec des coordonnées GTF/VCF/SAM à base 1. Convertissez explicitement (start BED + 1 → start à base 1) ou, mieux, importez les deux avec rtracklayer/GenomicRanges et laissez R tout garder à base 1.
« Pourquoi mon GTF/BED ne se charge-t-il pas ? » Ils sont séparés par des tabulations, pas par des espaces — un fichier édité dans un traitement de texte ou découpé sur les espaces sera corrompu. Ils peuvent aussi être compressés en gzip (.gtf.gz), et GTF/GFF portent des lignes d’en-tête préfixées par # plus une colonne 9 en texte libre sur laquelle les lecteurs CSV naïfs s’étranglent. Lisez-les avec un chargeur conscient du format (rtracklayer::import) plutôt qu’avec read.csv.
Essayer de lire un BAM comme du texte. cat, readLines ou head sur un .bam affiche du charabia binaire — le BAM est compressé. Visualisez-le avec samtools view aligned.bam (ou lisez-le avec Rsamtools::scanBam). Son jumeau texte, SAM, est lisible, mais il est volumineux ; vous gardez normalement le BAM et le décompressez à la demande.
Questions fréquentes
NoteQu’est-ce qu’un fichier FASTQ ?
Un fichier FASTQ contient des reads de séquençage bruts. Chaque read fait quatre lignes : un identifiant @, la séquence ADN, un séparateur +, et une chaîne de qualité Phred par base (un caractère par base, code ASCII moins 33 = le score de qualité). C’est du texte brut, généralement compressé en gzip sous .fastq.gz, et c’est ce qui sort directement du séquenceur avant l’alignement.
NoteQuelle est la différence entre SAM et BAM ?
Ils stockent les mêmes données de reads alignés. SAM est un texte délimité par des tabulations, lisible par l’humain ; BAM est ce texte compressé en binaire (et indexable). Le BAM est plus petit et c’est ce que consomment les outils en aval ; vous passez de l’un à l’autre avec samtools. Ne faites jamais cat sur un BAM — visualisez-le avec samtools view.
NoteQu’est-ce qu’un fichier VCF ?
Un fichier VCF (Variant Call Format) liste les positions où un échantillon diffère du génome de référence — SNP et petites insertions/délétions. Après un en-tête ##, il comporte 8 colonnes fixes (CHROM POS ID REF ALT QUAL FILTER INFO), puis une colonne FORMAT et une colonne de génotype par échantillon (0/1 hétérozygote, 1/1 homozygote alternatif). POS est à base 1.
NoteGTF vs GFF — quelle différence ?
Les deux décrivent l’annotation des gènes avec les mêmes 9 colonnes ; seule la colonne 9 (les attributs) diffère en syntaxe. GTF utilise gene_id "X"; gene_name "Y"; (guillemets, points-virgules) ; GFF3 utilise ID=X;Name=Y; (signes =, sans guillemets) et une clé Parent= pour imbriquer les exons sous les transcrits sous les gènes. Les outils de comptage comme featureCounts attendent généralement du GTF.
NoteBED est-il à base 0 ou à base 1 ?
BED est à base 0 et semi-ouvert : la première base est la position 0 et la coordonnée de fin n’est pas incluse. C’est l’inverse de GTF/GFF, SAM et VCF, qui sont tous à base 1 et inclusifs. Ainsi, les cinq premières bases d’un chromosome sont 0–5 en BED mais 1–5 en GTF — le même élément, des nombres différents. Vérifiez toujours quel système utilise un fichier avant de faire des calculs de coordonnées.
Testez vos connaissances
ImportantÀ vous : convertir des coordonnées entre BED et GTF
Un élément de gène dans un fichier GTF s’étend de start = 100 à end = 200 (à base 1, inclusif). (1) Quelle est sa longueur, en paires de bases ? (2) Quels sont ses chromStart et chromEnd dans un fichier BED (à base 0, semi-ouvert) ? (3) Confirmez que la longueur BED correspond.
AstuceIndice
Pour un élément à base 1 inclusif, la longueur est end - start + 1. Pour passer en BED, soustrayez 1 du début et laissez la fin inchangée ; une longueur BED est chromEnd - chromStart.
AstuceSolution
gtf_start <- 100; gtf_end <- 200
# (1) GTF length (inclusive):
gtf_len <- gtf_end - gtf_start + 1 # 101 bp
# (2) Same feature in BED (0-based start, end unchanged):
bed_start <- gtf_start - 1 # 99
bed_end <- gtf_end # 200
# (3) BED length (half-open) must match:
bed_len <- bed_end - bed_start # 101 bp
c(gtf_len = gtf_len, bed_start = bed_start, bed_end = bed_end, bed_len = bed_len)
#> gtf_len bed_start bed_end bed_len
#> 101 99 200 101L’élément fait 101 pb. En BED, il devient chromStart = 99, chromEnd = 200 — le début a baissé d’une unité, la fin est restée identique, et la longueur fait toujours 101. Retenez le start - 1 et n’oubliez rien d’autre.
NoteVérification rapide : quel fichier ouvririez-vous pour voir les variants génétiques d’un échantillon ?
A. Un fichier FASTQ. B. Un fichier BAM. C. Un fichier VCF.
AstuceAfficher la réponse
C. Un VCF liste les positions où l’échantillon diffère de la référence (SNP et indels). FASTQ contient les reads bruts, et BAM contient les reads alignés — les variants sont appelés à partir d’un BAM et écrits dans un VCF.
Conclusion
Cinq formats couvrent presque tout ce qu’un data scientist reçoit au début d’un projet omique. FASTQ, ce sont les reads bruts (quatre lignes chacun, séquence plus qualité Phred) ; SAM/BAM, ce sont ces reads alignés sur le génome (texte vs compressé en binaire) ; VCF, ce sont les variants qui en sont appelés ; GTF/GFF, c’est la carte des gènes contre laquelle les outils comptent ; et BED, ce sont de simples intervalles génomiques. Lisez leurs colonnes clés, prenez le bon parseur au lieu de read.csv, et surtout gardez les systèmes de coordonnées au clair — BED est à base 0 et semi-ouvert, tout le reste est à base 1. Une fois les fichiers démystifiés, l’étape suivante est de transformer les reads alignés en une matrice de comptage et de la conserver en sécurité dans un SummarizedExperiment.
Leçons connexes
- La matrice de comptage RNA-seq & le CQ — transforme les reads alignés (BAM) plus un GTF en la matrice gènes × échantillons. · Le conteneur SummarizedExperiment — l’objet qui réunit cette matrice avec ses tables d’échantillons et de gènes alignées. · La biologie pour data scientists — ce que signifient réellement un read et un comptage. · Bioinformatique — le pilier.
- Où cela s’inscrit : formats de fichiers → matrice de comptage & CQ → SummarizedExperiment → expression différentielle — reconnaissez les fichiers, puis analysez ce qu’ils contiennent.
Cette page vous a-t-elle été utile ?
Merci pour votre retour !
Note
Cette leçon est reproductible : chaque nombre de cette page a été produit par le code montré — copiez n’importe quel bloc et exécutez-le pour les reproduire. The runtime is the judge.
Réutilisation
Citation
BibTeX
@online{2026,
author = {},
title = {Les formats de fichiers en bioinformatique : FASTQ, SAM/BAM,
VCF, GTF/GFF \& BED expliqués},
date = {2026-06-29},
url = {https://www.datanovia.com/learn/bioinformatics/foundations/bioinformatics-file-formats},
langid = {fr}
}
Veuillez citer ce travail comme suit :
“Les formats de fichiers en bioinformatique : FASTQ, SAM/BAM, VCF,
GTF/GFF & BED expliqués.” 2026. June 29. https://www.datanovia.com/learn/bioinformatics/foundations/bioinformatics-file-formats.
Comment cela se relie au reste du pilier
Ces fichiers sont la matière première ; les séries d’analyse les transforment en quelque chose de modélisable. Les reads alignés d’un BAM sont quantifiés contre un GTF en la matrice de comptage RNA-seq — gènes × échantillons — qui, avec ses tables d’échantillons et de gènes, vit dans un conteneur SummarizedExperiment. Reconnaissez les formats ici, et ces leçons portent sur l’analyse, pas sur la lutte contre le fichier.