Découper un fichier trop gros pour être envoyé
Publié le 13/07/2026 · 8 min de lecture · Outils fichiers
Daniel Okonkwo — Développeur front-end et rédacteur Tech chez Allin
Performance web · Formats de fichiers
Vérifié à partir de 3 sources
Le découpage coupe le fichier à des frontières d'octets, et rien d'autre. Il ne comprend pas ce qu'est le fichier : les morceaux ne sont donc pas des versions réduites de celui-ci — la partie un d'une vidéo ne se lira pas, la partie un d'une archive ne s'ouvrira pas, et chaque pièce est inerte tant que toutes ne sont pas rejointes dans l'ordre exact où elles ont été coupées. C'est le marché, et à l'intérieur de ce marché l'outil est parfaitement fiable : rejoindre les morceaux reproduit l'original octet pour octet, car rien n'a été décodé, ré-encodé ni interprété en chemin. Trois choses font trébucher. D'abord, la taille que tu régles est en mébioctets et non en mégaoctets : un morceau réglé sur 10 sort à 10 485 760 octets, soit 4,86 % au-dessus d'une limite qui signifie 10 000 000 — assez pour être refusé. Règle le morceau en dessous de la limite plutôt qu'à égalité — 9 contre un plafond de 10 Mo, 20 contre 25 — et la marge absorbera aussi le surcoût d'encodage qu'ajoute le courriel. Ensuite, l'ordre est absolu et irrécupérable depuis le contenu : les morceaux sont numérotés pour une raison, et un destinataire qui les enregistre dans le désordre ou les renomme obtient un fichier corrompu sans aucun avertissement, car concaténer la mauvaise séquence produit quand même un fichier. Enfin, un destinataire qui ne sait pas les rejoindre n'a rien reçu du tout : c'est donc une technique pour quelqu'un à qui tu peux donner une consigne, pas pour un inconnu ni pour un formulaire. Avant d'y recourir, assure-toi que les alternatives sont épuisées : compresser le fichier, envoyer un lien, ou découper le contenu plutôt que les octets — un PDF de cent pages envoyé en deux PDF de cinquante donne au destinataire deux documents qu'il peut chacun ouvrir, ce qui vaut presque toujours mieux que deux moitiés d'un seul qu'il ne peut pas.
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.
Une coupe d'octets, pas une coupe de contenu
L'outil lit le fichier comme un flux d'octets et le coupe à intervalles fixes. Il ne demande jamais ce que les octets signifient, ce qui explique à la fois qu'il fonctionne sur n'importe quoi — une vidéo, un export de base, une archive, une image disque — et que les morceaux soient inertes. Un format de fichier est une structure : un en-tête au début, un index quelque part, et du contenu qui renvoie aux deux. Coupe-le en trois et le premier morceau porte un en-tête décrivant un contenu qu'il ne contient plus, tandis que le dernier porte du contenu que rien ne désigne.
La contrepartie est que l'opération est parfaitement réversible. Rien n'est interprété, donc rien ne peut être mal interprété : concaténer les morceaux dans l'ordre redonne exactement les octets entrés, et le résultat est le fichier d'origine et non une copie. C'est une garantie plus forte que celle de la plupart des opérations sur fichiers, et c'est ce qui fait du découpage un dernier recours raisonnable plutôt qu'un geste désespéré.
Le mégaoctet que tu régles n'est pas celui de la limite
Les tailles de morceau sont ici en mébioctets : une valeur de 10 signifie 10 × 1024 × 1024 = 10 485 760 octets. Un service qui annonce une limite de 10 Mo entend généralement 10 000 000 : un morceau réglé exactement sur la limite la dépasse donc de 4,86 % et se fait refuser, échec déroutant puisque le nombre à l'écran correspond au nombre de la règle. La proportion est la même à toutes les tailles : 25 donne 26 214 400 contre un plafond de 25 Mo, et 50 donne 52 428 800.
Laisse une marge plutôt que de faire la conversion de tête. Neuf contre un plafond de dix mégaoctets et vingt contre vingt-cinq sont confortables, et le jeu rend un second service : une pièce jointe de courriel est encodée pour le transport, ce qui ajoute environ un tiers à ce qui quitte ta machine — un morceau qui tient tout juste sur le disque peut ne pas tenir dans un message.
L'ordre est tout, et rien ne t'avertit
Les morceaux ne portent aucune marque disant où ils vont ; leur position vit entièrement dans leur nom. Rejoins-les dans le mauvais ordre et tu n'obtiens pas d'erreur — tu obtiens un fichier de la bonne taille exactement, et parfaitement absurde, et ce qui l'ouvrira signalera une corruption plutôt qu'un mauvais ordre. Dis au destinataire de conserver les noms, et utilise deux chiffres dès le départ s'il peut y avoir plus de neuf morceaux, pour la même raison de tri qui mélange les PDF fusionnés.
Trois choses à essayer avant de découper
Compresse d'abord, car un fichier qui passe n'exige aucune explication à l'arrivée. Envisage ensuite un lien : la plupart des gens disposent aujourd'hui d'un endroit où déposer un fichier et envoyer une adresse, et un destinataire qui clique a réussi, là où un destinataire qui doit rejoindre trois morceaux peut échouer. Puis découpe le contenu plutôt que les octets — des pages, des chapitres, des pistes, un dossier d'images envoyé en trois dossiers. Un découpage de contenu produit des pièces qui s'ouvrent chacune, ce qui fait la différence entre envoyer quelque chose d'utilisable et envoyer une énigme.
| Valeur réglée | Octets produits | Face à une limite de | Verdict |
|---|---|---|---|
| 10 | 10 485 760 | 10 Mo = 10 000 000 | Refusé — 4,86 % au-dessus |
| 9 | 9 437 184 | 10 Mo = 10 000 000 | Passe, avec de la place pour l'encodage de transport |
| 25 | 26 214 400 | 25 Mo = 25 000 000 | Refusé — 4,86 % au-dessus |
| 20 | 20 971 520 | 25 Mo = 25 000 000 | Passe confortablement |
Questions fréquentes
- Le destinataire peut-il ouvrir la partie un toute seule ?
- Non, et mieux vaut le dire dans le message plutôt que de le laisser le découvrir. La coupe est à une position d'octet sans égard pour la structure : la partie un d'une vidéo a un en-tête et pas d'index, la partie un d'une archive a un catalogue décrivant des fichiers absents, et la partie un d'un PDF a un début sans table de références. Chaque pièce a besoin de toutes les autres.
- Le fichier rejoint est-il identique à l'original ?
- Octet pour octet, à condition que l'ordre soit bon et qu'aucun morceau ne manque. Rien n'est décodé ni ré-encodé de part et d'autre : il n'y a donc aucune génération de perte et aucune interprétation à rater. Pour en être certain, compare la taille du fichier rejoint à celle de l'original — un écart signifie qu'un morceau manque ou est en double, et une taille juste avec un résultat corrompu signifie que l'ordre était faux.
- Faut-il zipper le fichier avant de le découper ?
- Seulement s'il s'agit du genre de données qui se compresse — un export de base, du code source, des journaux, du texte non compressé. Si c'est déjà une vidéo, une image, un fichier audio ou un PDF, l'archive gagnera un ou deux pour cent et ajoutera une étape au destinataire. Là où un zip aide, c'est pour l'emballage : une archive découpée en morceaux est plus propre qu'un dossier de fichiers épars découpés un à un, et le destinataire ne rejoint qu'une fois au lieu de plusieurs.
- Le destinataire est sur un autre système. Est-ce un problème ?
- Pas pour les octets — une concaténation est une concaténation partout. Cela compte pour la façon de la faire : la commande diffère selon les systèmes, et un outil de fusion dans le navigateur évite entièrement la question en fonctionnant pareil partout. Envoyer une consigne d'une ligne avec les morceaux fait la différence entre un destinataire qui réussit en une minute et un destinataire qui te réécrit.
- À partir de combien de morceaux est-ce trop ?
- Au-delà de trois ou quatre, le taux d'échec à l'arrivée grimpe plus vite que le confort. Un fichier de 700 Mo en morceaux de 20 mébioctets fait 34 pièces jointes, ce qui n'est pas une livraison mais une corvée, et un seul morceau manquant invalide tous les autres. À ce stade, un lien est la réponse honnête. Le découpage gagne sa place quand un fichier dépasse un peu une limite, pas quand il la dépasse plusieurs fois.
Articles qui pourraient t'intéresser
Tous les guides →Outils similaires
Le comportement décrit ici pour les outils de ce site a été lu dans leur code source le 13 août 2026 et mesuré sur les bibliothèques qu'ils embarquent. Le comportement d'un tableur dépend de la version, de la build et des paramètres régionaux de la machine devant toi — Microsoft a changé plusieurs de ces valeurs par défaut, alors vérifie les vôtres plutôt que de croire un article, celui-ci compris.
Sources
Tu as repéré une erreur dans cet article ?