Un gigaoctet de CSV représente environ cinq à dix millions de lignes de données tabulaires ordinaires. Ce chiffre compte plus que le gigaoctet, parce qu'il vaut déjà cinq fois ce qu'une feuille de calcul peut contenir. Première chose à admettre : « l'ouvrir dans Excel » n'a jamais été une option.
Ce qui reste dépend d'une seule question : avez-vous besoin de regarder le fichier, ou d'en tirer une réponse ?
- Une réponse — un total, un filtre, une jointure, un décompte de doublons : DuckDB. Une commande, dix secondes, aucun import.
- Regarder — faire défiler, chercher, se faire une idée de la forme des données : un lecteur conçu pour le streaming. EmEditor sous Windows,
lesspartout, une application mobile si le fichier est sur votre téléphone. - Modifier et réenregistrer : le cas le plus difficile, avec le moins de bonnes réponses. Voir plus bas.
Le comparatif
Les durées valent pour un fichier de 1 Go d'environ 8 millions de lignes, sur un portable ordinaire avec 16 Go de RAM et un SSD. Elles sont indicatives, ce ne sont pas des benchmarks. Vos colonnes et votre disque les feront bouger. La dernière colonne, elle, ne bouge pas.
| Outil | Ouvre 1 Go ? | Temps avant la 1re ligne | RAM max | Coût |
|---|---|---|---|---|
| Excel | Non — plafond de 1 048 576 lignes | — | — | Payant |
| Excel + Power Query | Oui, comme étape de chargement | Minutes | Élevée | Payant |
| Google Sheets | Non — 10 M de cellules, ~100 Mo en envoi | — | — | Gratuit |
| Numbers | Non — 1 M de lignes, et lent bien avant | — | — | Gratuit |
| DuckDB | Oui | ~1 s | ~200 Mo | Gratuit |
| Python + pandas | Oui, avec chunksize | 30 s+ | 5–10 Go en version naïve | Gratuit |
| Python + Polars | Oui | ~5 s | ~1,5 Go | Gratuit |
| EmEditor (Windows) | Oui, sans effort | ~5 s | Faible | Payant |
| VS Code | Peine | 30 s+ | Élevée | Gratuit |
less / head / awk | Oui | Instantané | ~0 | Gratuit |
| OpenRefine | Oui, lentement | Minutes | Élevée | Gratuit |
| Appli CSV mobile | Oui, si elle est conçue pour | Secondes | Gérée | Version gratuite |
Deux lignes sont des pièges. Google Sheets annonce 10 millions de cellules, ce qui semble proche, mais un fichier de 20 colonnes atteint cette limite à 500 000 lignes, et la limite d'envoi vous arrête bien avant. pandas ouvre volontiers le fichier, puis consomme huit fois sa taille en RAM, parce qu'il stocke chaque colonne de texte sous forme d'objets Python. C'est le fameux « ça s'est ouvert, mais le portable est mort », avec le swap qui s'emballe.
Selon ce que vous faites vraiment
Vous avez besoin d'une réponse
DuckDB, et ce n'est même pas serré :
duckdb -c "SELECT region, COUNT(*), SUM(amount) FROM 'big.csv' GROUP BY region"
Il lit le fichier en parallèle, en flux plutôt qu'en le chargeant, et n'alloue jamais beaucoup plus que l'espace de travail de votre requête. Un GROUP BY sur 8 millions de lignes se termine en quelques secondes. Le tour complet (forcer les types, joindre deux fichiers, réécrire les résultats) se trouve dans exécuter des requêtes SQL sur un CSV sans base de données.
Si vous préférez rester en Python, utilisez Polars avec scan_csv (paresseux : il planifie toute la requête avant de lire) ou pandas avec un chunksize explicite et une table dtype. Le pd.read_csv('big.csv') naïf est à éviter.
Vous avez besoin de regarder le fichier
Sous Windows, EmEditor. C'est le seul éditeur de gros fichiers qui tienne la route, et il ouvre des CSV de plusieurs Go sous forme de grille, avec tri et filtre. Il est payant ; il vaut son prix si le problème revient régulièrement.
Partout, le shell. Sous-estimé pour les cinq premières minutes avec n'importe quel gros fichier :
head -5 big.csv # what are the columns
wc -l big.csv # how many rows really
awk -F, 'NR<=1000' big.csv > sample.csv # a slice you can open normally
less -S big.csv # scroll it, no line wrapping
Créer un échantillon de 1 000 lignes et ouvrir celui-là dans Excel répond à « qu'y a-t-il dans ce fichier ? » plus vite que n'importe quel outil qui ouvre tout.
Ni VS Code, ni Notepad++. Tous deux chargent le fichier entier en mémoire comme du texte. Ils y arrivent, mais lentement, avec un avertissement, et sans vue en tableau utilisable à la fin.
Le fichier est sur votre téléphone
Le cas du 1 Go est difficile ici : les téléphones ont moins de RAM que les portables et des limites plus strictes sur ce qu'une appli peut garder. Rien sur un téléphone n'ouvre confortablement un gigaoctet complet, donc testez toute appli qui prétend le contraire avant de lui faire confiance. Ce que les applis mobiles font bien, c'est la tranche juste en dessous : les exports de 100 à 500 Mo, de plusieurs centaines de milliers de lignes, qu'un tableur mobile tronque en silence.
Ouvre les gros fichiers sans les tronquer, puis répond aux questions sur les données en SQL ou en langage courant, ce qu'on attend le plus souvent d'un fichier trop gros pour défiler. iOS et Android.
Ce que ça faitAvant de confier un fichier important à une appli mobile, faites la vérification décrite dans la dernière section de cette page.
Vous devez le modifier et le réenregistrer
C'est le cas qui a le moins de réponses honnêtes, car « modifier » veut dire tenir le fichier en mémoire puis le réécrire en entier.
- Quelques changements ciblés — corriger une valeur, supprimer une colonne : faites-le avec DuckDB ou
awket écrivez un nouveau fichier. C'est plus rapide que n'importe quel outil interactif et l'original reste intact. - Vraie modification interactive sous Windows : EmEditor.
- Vraie modification interactive ailleurs : découpez d'abord le fichier.
split -l 1000000 big.csv part_donne des morceaux qu'un tableur peut contenir, au prix de devoir les réassembler (catfonctionne, mais supprimez les lignes d'en-tête répétées). - Sous environ 500 000 lignes, un éditeur mobile s'en charge directement :
Édition façon tableur sur des fichiers de 500 000 lignes, chaque ligne étant réécrite à l'enregistrement, y compris dans la version gratuite. iOS et iPadOS.
Ce que ça faitFaire disparaître le problème par conversion
Si vous touchez le fichier plus de deux fois, cessez de le traiter comme un CSV :
duckdb -c "COPY (SELECT * FROM 'big.csv') TO 'big.parquet'"
Parquet est en colonnes, typé et compressé. Le CSV de 1 Go tombe à 100–200 Mo, les requêtes qui balaient quelques colonnes vont cinq à vingt fois plus vite, et les types sur lesquels vous butiez sont maintenant stockés dans le fichier. DuckDB, Polars et pandas le lisent nativement. Ce sont les dix secondes les plus rentables de cet article.
Vérifier qu'un outil a vraiment ouvert tout le fichier
Beaucoup d'outils ouvrent un gros CSV en n'en ouvrant qu'une partie, sans dire laquelle. Avant de tirer une conclusion d'un fichier, vérifiez :
- Comptez d'abord les lignes, hors de l'outil :
wc -l big.csv. Retirez-en une pour l'en-tête. - Allez à la dernière ligne dans l'outil et comparez le nombre.
- Comparez le contenu de la dernière ligne avec
tail -1 big.csv.
Si ça ne concorde pas, l'outil a tronqué. Toute conclusion que vous en tirez (un total, un maximum, « il n'y a aucune commande dans cette région ») est alors fausse, sans que rien à l'écran ne vous le signale. La troncature silencieuse est le vrai danger avec les gros fichiers, plus que les plantages : un plantage a au moins le mérite d'être honnête.
Si c'est précisément Excel qui a échoué
Deux problèmes voisins, faciles à confondre. Si Excel a refusé le fichier ou n'en a montré qu'une partie, c'est le plafond de lignes, et comment ouvrir un gros fichier CSV qu'Excel n'ouvre pas présente les moyens de le contourner. Si Excel a ouvert le fichier puis s'est figé, a planté ou s'est bloqué, c'est une autre panne avec d'autres causes, détaillée dans pourquoi Excel plante sur les gros fichiers.