Aller au contenu
OneKitly

ZIP ou TAR : lequel choisir, et pourquoi cela change tout

Publié le 21/08/2026 · 13 min de lecture · Outils fichiers

Daniel Okonkwo

Daniel OkonkwoDéveloppeur front-end et rédacteur Tech chez OneKitly

Performance web · Formats de fichiers

Vérifié à partir de 4 sources

Voir le profil
En bref

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.

Les mêmes critères appliqués aux deux, et à leur combinaison — mesurés sur la même arborescence de 60 fichiers, 11 604 octets de source
CritèreTAR seulZIPTAR + gzip (.tar.gz)
Taille de l'arborescence d'essai63 488 octets — plus gros que la source14 686 octets1 809 octets
Où se produit la compressionNulle part — il ne fait qu'empilerPar membre, fenêtre réinitialisée à chaque foisUne fois, sur tout le flux
Extraire un fichier sans lire le resteEn partie — les en-têtes sont en ligne, mais il faut les parcourirOui — répertoire central en fin de fichierNon — décompresser depuis le début
Permissions Unix et liens symboliquesNatifs — mode, propriétaire et type dans chaque en-têteFacultatifs — le zip système les stocke, beaucoup d'autres nonNatifs — la couche gzip n'y change rien
S'ouvre sans rien installerWindows 11 et Unix ; pas Windows 10Partout, depuis vingt-cinq ansWindows 11 et Unix ; pas Windows 10
Un dégât au milieu te coûteUn membre, en grosUn membre ; le répertoire liste toujours le resteTout ce qui suit le dégât
TAR en ZIPReconditionne une archive .tar, .tar.gz ou .tgz en ZIP, que Windows ouvre sans logiciel supplémentaire.Essayer l'outil

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
TutorielDécouper un fichier trop gros pour être envoyéLe dernier recours quand plus rien ne peut être compressé. Cela fonctionne, avec trois arêtes vives : les morceaux ne servent à rien seuls, l'ordre est absolu, et le mégaoctet que tu régles n'est pas celui de la limite.ExplicationConvertir les formules en valeurs garde la réponse en cache, pas le calculUn fichier de tableur range à la fois la formule et la dernière réponse calculée par Excel. Retirer la formule laisse la réponse enregistrée — et laisse un vide partout où le fichier n'en portait pas.ExplicationLe nombre 1 et le texte « 1 » ne sont pas des doublonsLe dédoublonnage compare des lignes entières à l'identique, type de cellule compris. Cinq lignes d'apparence identique en ont donné trois : l'une portait un nombre, l'autre une chaîne, la troisième une chaîne précédée d'une espace.ComparatifXLS, XLSX, XLSM et XLSB : lequel est lequel, et lequel te faut-ilQuatre extensions, dont trois sont la même boîte avec des couvercles différents. Renomme un XLSX en .zip et il s'ouvre — ce seul fait explique toute la famille, et explique pourquoi XLS, qui ne s'ouvre pas ainsi, reste celui qui pose problème.TutorielNuméroter un PDF quand les pages sont pivotées ou de formats différentsNuméroter un document bien rangé est trivial. Ce qui mord, c'est une page couchée, une feuille Letter au milieu de A4, un fichier d'impression avec fond perdu, et un document qui imprime déjà son propre numéro. Les quatre ont été testés : sur les trois premiers le numéro se pose exactement où tu l'as demandé, et le quatrième n'est pas détecté du tout.GuideCe qu'un PDF dit de toi : lire et effacer ses métadonnéesUn PDF porte ses métadonnées deux fois, dans deux magasins qui peuvent raconter des histoires différentes, et aucun des deux n'est l'histoire complète. Voici ce qui est réellement dans le fichier, ce qu'un effacement retire, et les deux choses qui survivent à tout nettoyage.

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 ?