ZIP ou TAR : lequel choisir, et pourquoi cela change tout
Publié le 21/08/2026 · 13 min de lecture · Outils fichiers
Daniel Okonkwo — Développeur front-end et rédacteur Tech chez OneKitly
Performance web · Formats de fichiers
Vérifié à partir de 4 sources
Envoie un ZIP si tu ne sais pas ce que fait tourner le destinataire. Prends un .tar.gz si les fichiers sont nombreux, petits et semblables, ou si les permissions et les liens symboliques doivent survivre. Tout le reste découle d'un fait de structure : TAR ne compresse pas du tout — il met les fichiers bout à bout derrière des en-têtes de 512 octets — tandis que ZIP compresse chaque membre séparément. La compression est ensuite appliquée au TAR entier comme à un seul flux, d'où la double extension. Voilà ce que cela vaut, mesuré. Soixante fichiers JavaScript quasi identiques, 193 octets chacun, 11 604 octets de source au total. En .tar simple : 63 488 octets — cinq fois et demie la source, parce que chaque membre est complété jusqu'à un bloc entier de 512 octets. En .tar.gz : 1 809 octets. En .zip : 14 686 octets. Le .tar.gz est huit fois plus petit que le .zip contenant exactement les mêmes fichiers, et monter le curseur de compression du ZIP ne change strictement rien — l'archive fait 14 490 octets à tous les niveaux de 1 à 9, parce que chaque membre pèse 193 octets et qu'il n'y a rien à trouver à l'intérieur d'un seul fichier. Gzip, lui, les voit tous les soixante d'un coup et repère qu'ils se répètent. Le prix est l'image inverse : un ZIP porte un répertoire central, donc un lecteur saute directement à un membre ; un .tar.gz n'a aucun index, donc extraire un fichier oblige à décompresser le flux depuis le début. Voilà l'échange, et aucun des deux ne le gagne franchement.
Une seule différence de structure explique tout le reste : TAR ne compresse pas, il empile ; ZIP compresse chaque fichier séparément. Mesuré sur 60 petits fichiers source, cela fait 1 809 octets contre 14 686.
La différence de structure, en un paragraphe
Un fichier TAR est une pile. Pour chaque membre il écrit un en-tête de 512 octets — le nom, les droits, le propriétaire, la taille en octal, la date de modification, une somme de contrôle, un indicateur de type — puis les octets du fichier, puis un remplissage jusqu'au bloc entier de 512 octets suivant. Deux blocs de zéros marquent la fin. Pas d'index, pas de compression, pas de comptabilité astucieuse : c'est tout le format, et il n'a presque pas changé depuis qu'il a été conçu pour les dérouleurs de bande, d'où son nom.
Un ZIP est un classeur. Chaque membre est compressé séparément avec deflate et écrit avec son propre en-tête local ; à la fin du fichier vient un répertoire central qui liste chaque membre, sa taille, sa taille compressée et l'endroit où il commence. Un lecteur ouvre les derniers kilo-octets, lit le répertoire, et connaît tout le contenu sans toucher un octet des données. C'est cette conception qui permet à un client de messagerie de te montrer l'intérieur d'une pièce jointe avant que tu ne l'extraies.
Tout le reste de cet article découle de ces deux paragraphes. La taille, l'extraction d'un fichier isolé, les permissions, les liens symboliques, le comportement face à la corruption — rien de tout cela n'est arbitraire, et rien n'exige d'apprendre par cœur un tableau comparatif dès qu'on se représente une pile d'un côté et un classeur de l'autre.
Pourquoi .tar.gz gagne sur beaucoup de petits fichiers semblables
Deflate travaille en repérant les répétitions à l'intérieur d'une fenêtre glissante et en remplaçant la seconde copie par une référence courte. Dans un ZIP, cette fenêtre est remise à zéro au début de chaque membre : un compresseur qui regarde un fichier JavaScript de 193 octets n'a presque rien à se mettre sous la dent — les imports, le passe-partout et l'accolade finale sont présents dans les cinquante-neuf autres fichiers, et il ne les verra jamais. Dans un .tar.gz, on lui remet un flux continu de 63 488 octets où ces cinquante-neuf copies sont juste là, à quelques centaines d'octets d'écart.
La mesure rend cela concret. Les mêmes soixante fichiers : 1 809 octets en .tar.gz contre 14 686 en .zip. Ce n'est pas une affaire de réglage. Passer ces soixante fichiers dans un rédacteur ZIP à tous les niveaux de compression de 1 à 9 a produit neuf fois la même archive de 14 490 octets, à l'octet près — le curseur n'est relié à rien, parce qu'il n'y a rien, dans un fichier de 193 octets, sur quoi le réglage maximal puisse travailler davantage. Au niveau 0, qui stocke au lieu de compresser, le ZIP faisait 18 328 octets : la compression fait donc bien quelque chose ; elle le fait simplement au mauvais endroit.
Retourne le corpus et l'avantage s'évapore. Compresse un seul fichier texte de 92 Ko : 33 202 octets en ZIP à un membre, 33 110 octets en gzip — 92 octets d'écart, trois pour mille. Il n'y a pas de redondance entre fichiers quand il n'y a qu'un fichier. La règle n'est donc pas « tar.gz est meilleur », c'est : plus les membres sont nombreux, petits et semblables, plus l'écart est grand ; un seul gros fichier, aucun écart.
Le coût : pas d'index, et aucun moyen d'attraper un seul fichier
La compression solide est précisément la raison pour laquelle on n'ouvre pas un .tar.gz par le milieu. Le flux compressé est une longue chaîne où l'octet numéro un million dépend de tout ce qui précède : un programme à qui on demande le dernier de soixante fichiers doit décompresser les cinquante-neuf premiers pour y arriver. Un ZIP fait l'inverse : les archives construites pour cet article portent un enregistrement de répertoire central pour chaque membre, et un lecteur y saute, trouve la position, et décompresse 193 octets.
La même asymétrie décide de ce qui se passe quand une archive est abîmée. Corromps quelques octets dans un ZIP et tu perds en général le membre auquel ils appartiennent ; le répertoire central liste toujours le reste et un outil de réparation peut souvent le récupérer. Corromps quelques octets près du début d'un .tar.gz et tout ce qui suit le dégât devient inaccessible, parce que l'état du décompresseur est perdu. Si tu écris sur un support peu fiable, ou si tu transfères sur un lien qui coupe, cette différence n'a rien d'académique.
Permissions et liens symboliques : ce que ce convertisseur a réellement perdu
L'arborescence d'essai ne contenait pas que soixante fichiers. Elle portait aussi un répertoire, un fichier marqué exécutable et un lien symbolique pointant vers un autre fichier. Empaquetés par les outils système, les deux formats ont tout conservé. Le .tar portait un mode 000755 sur l'exécutable et un indicateur de type 2 sur le lien. Le .zip portait 62 entrées de répertoire central : les soixante fichiers, le répertoire en 040755, l'exécutable en 0100755, et latest.js en 0120755 — un lien symbolique, long de dix-sept octets, ces octets étant le chemin qu'il désigne.
Ce dernier fait mérite un arrêt, car la légende veut que le ZIP ne puisse pas porter de métadonnées Unix. Il le peut. Le format réserve un champ précisément pour cela, et l'outil zip standard sous Unix le remplit. Ce qui est vrai, c'est que ce champ est facultatif, que c'est le rédacteur qui décide de le remplir, et qu'un très grand nombre de rédacteurs ne le remplissent pas.
Le convertisseur de cette page en fait partie, et l'exécuter l'a rendu visible. Son lecteur TAR ne garde que les entrées dont l'indicateur de type dit « fichier ordinaire » : le répertoire et le lien symbolique ont donc été écartés sans un mot — soixante membres entrés, soixante sortis, et deux objets disparus. Sa représentation interne d'un membre est un chemin et un bloc d'octets, sans champ pour les droits : le 000755 de l'en-tête tar n'a nulle part où aller. L'inspection du ZIP produit le confirme : 60 entrées, toutes déclarées comme venant d'un système de type DOS, chaque champ de permission à zéro. Pas de répertoire, pas de lien, pas de bit d'exécution.
Pour la tâche à laquelle cette page sert — un .tar.gz qu'on t'a envoyé, dont tu veux le contenu sur une machine qui refuse de l'ouvrir — rien de tout cela n'a d'importance. Pour reconditionner une livraison, une sauvegarde ou quoi que ce soit contenant des scripts, tout cela compte, et il vaut mieux reconditionner avec les outils système. Savoir dans lequel des deux cas on se trouve, c'est toute la compétence.
Lequel le destinataire peut-il ouvrir sans rien installer
C'est en général ce qui tranche, et la réponse honnête a changé. Le ZIP est lisible dans l'explorateur Windows depuis 2001 et dans l'utilitaire d'archive de macOS depuis le début ; il n'y a jamais eu de machine où envoyer un ZIP était un mauvais pari. Le TAR, c'était l'inverse : hors Unix, il fallait un programme tiers, c'est-à-dire demander à un collègue d'installer un logiciel avant de pouvoir lire ta pièce jointe.
Cet écart s'est refermé. Windows 11 a ajouté la lecture native des .tar, .tar.gz, .tgz, .tar.bz2, .tar.xz, .tar.zst, .rar et .7z dans l'explorateur de fichiers, annoncée en 2023 et livrée au fil des versions suivantes. Sur un Windows 11 à jour, un .tar.gz s'ouvre donc d'un double-clic sans rien installer. Le hic, c'est tout ce qui n'est pas un Windows 11 à jour : les postes sous Windows 10, les images d'entreprise verrouillées, l'aperçu web d'un client de messagerie, une GED, un téléphone. Le ZIP fonctionne partout.
La règle pratique est donc asymétrique, et elle ne dit pas quel format est meilleur. Si tu stockes, déploies ou déplaces des fichiers entre des machines que tu maîtrises : .tar.gz — plus petit sur les arborescences de code, et il conserve les métadonnées. Si tu envoies à une personne : ZIP, sauf si tu sais ce qu'elle utilise. Convertir de l'un à l'autre prend quelques secondes, et c'est à cela que sert l'outil de cette page ; fais simplement la conversion dans le sens qui ne perd rien de ce qui t'importe.
| Critère | TAR seul | ZIP | TAR + gzip (.tar.gz) |
|---|---|---|---|
| Taille de l'arborescence d'essai | 63 488 octets — plus gros que la source | 14 686 octets | 1 809 octets |
| Où se produit la compression | Nulle part — il ne fait qu'empiler | Par membre, fenêtre réinitialisée à chaque fois | Une fois, sur tout le flux |
| Extraire un fichier sans lire le reste | En partie — les en-têtes sont en ligne, mais il faut les parcourir | Oui — répertoire central en fin de fichier | Non — décompresser depuis le début |
| Permissions Unix et liens symboliques | Natifs — mode, propriétaire et type dans chaque en-tête | Facultatifs — le zip système les stocke, beaucoup d'autres non | Natifs — la couche gzip n'y change rien |
| S'ouvre sans rien installer | Windows 11 et Unix ; pas Windows 10 | Partout, depuis vingt-cinq ans | Windows 11 et Unix ; pas Windows 10 |
| Un dégât au milieu te coûte | Un membre, en gros | Un membre ; le répertoire liste toujours le reste | Tout ce qui suit le dégât |
Questions fréquentes
- Un .tgz est-il la même chose qu'un .tar.gz ?
- Oui, à l'octet près. .tgz est une contraction née parce que MS-DOS n'autorisait que trois caractères après le point, et elle a survécu à sa raison d'être. Tout ce qui lit l'un lit l'autre. Idem pour .tbz2 et .tar.bz2, .txz et .tar.xz, .tzst et .tar.zst. Le convertisseur d'ici renifle les octets plutôt que l'extension : il accepte donc n'importe laquelle de ces graphies — et il accepte aussi un fichier dont le nom est faux, ce qui est plus souvent la vraie situation.
- Pourquoi mon .tar est-il plus gros que les fichiers qu'il contient ?
- Parce que TAR ne compresse pas et parce qu'il arrondit. Chaque membre coûte un en-tête de 512 octets plus ses propres octets complétés jusqu'à un bloc entier de 512 octets, et l'archive se termine par 1 024 octets de zéros. Sur l'arborescence d'essai, cela a transformé 11 604 octets de source en un .tar de 63 488 octets — cinq fois et demie plus gros, parce que soixante fichiers de 193 octets occupent chacun un kilo-octet complet d'en-tête et de remplissage. Ce n'est pas un défaut : c'est l'allure d'un format conçu pour être écrit sur bande en blocs fixes. Compresse-le, et le remplissage, fait de zéros, disparaît presque entièrement.
- Convertir un .tar.gz en ZIP va-t-il l'agrandir ?
- Souvent oui, et parfois beaucoup. Le sens de la conversion défait précisément ce qui rendait le .tar.gz petit : l'archive est dépaquetée en fichiers individuels, puis chacun est compressé séparément. Sur l'arborescence d'essai de soixante fichiers, le ZIP de sortie faisait 14 490 octets contre 1 809 en entrée — huit fois plus pour le même contenu. Si l'archive contient quelques gros fichiers déjà compressés (photos, vidéo, un export de base gzippé avant d'y entrer), l'écart sera presque nul. Si elle contient une arborescence de code, attends-toi à un bond.
- Le niveau de compression de l'outil sert-il à quelque chose ?
- Entre « aucune » et les deux autres, oui : stocker au lieu de compresser donnait 18 328 octets contre 14 490 sur l'arborescence d'essai. Entre « normale » et « maximale », sur cette même arborescence, non — les deux ont produit des fichiers identiques, comme tous les niveaux intermédiaires. Sur un unique document de 92 Ko, le réglage maximal a économisé 39 octets par rapport au réglage par défaut. Les niveaux de compression se justifient sur des membres volumineux et riches en texte ; sur un tas de petits, c'est un curseur relié à rien. Choisis « aucune » quand le contenu est déjà compressé et que tu ne veux qu'un conteneur, et laisse sur normale sinon.
- Puis-je conserver les permissions en convertissant TAR en ZIP ici ?
- Non, et l'outil ne le dit pas. Sa représentation interne d'un membre est un chemin et un bloc d'octets, sans champ pour les droits : les permissions des en-têtes tar sont dépassées à la lecture et jamais réécrites ; le ZIP produit pour cet article avait un champ de permission à zéro sur ses soixante membres. Les liens symboliques et les entrées de répertoire sont écartés pour la même raison — seuls les membres marqués comme fichiers ordinaires sont conservés. Si cela compte, reconditionne avec tar et zip en ligne de commande, où les deux formats portent nativement les métadonnées. Si tu cherches seulement à lire l'archive de quelqu'un sur une machine qui refuse de l'ouvrir, rien de tout cela ne te concerne.
Articles qui pourraient t'intéresser
Tous les guides →Outils similaires
Ceci décrit ce que font aujourd'hui ces convertisseurs, vérifié en exécutant leur propre code sur de vrais fichiers, et non ce qu'ils devraient faire. Le comportement d'un format dépend de la version d'Excel, de LibreOffice ou de Numbers qui a écrit le fichier et de celle qui l'ouvrira : garde donc l'original tant que tu n'as pas ouvert la copie convertie et que tu ne l'as pas regardée. Tout ce qui compte — un classeur à macros, un modèle plein de formules, un fichier dont quelqu'un d'autre dépendra — se vérifie cellule par cellule après conversion, plutôt que de se croire sur parole parce qu'une barre de progression est allée au bout.
Sources
Tu as repéré une erreur dans cet article ?