Pourquoi Excel supprime les zéros non significatifs de vos codes CSV, et comment les conserver (Guide 2026)

Diagnostiquez en 30 secondes : le fichier est correct, c'est Excel qui a mal deviné

La première chose à établir quand vos codes perdent leurs zéros, c'est de savoir si les données sont abîmées ou simplement mal lues, car les deux cas appellent des solutions très différentes, et une mauvaise solution peut transformer un simple problème d'affichage en véritable perte de données. Voici le test de 30 secondes. Ouvrez le même fichier dans un simple éditeur de texte, le Bloc-notes sur Windows ou TextEdit en mode texte brut sur Mac. Si les codes y affichent tous leurs zéros, 00123, 02138, 07477, vos données sont intactes et seul l'affichage d'Excel est fautif. Le fichier sur le disque contient les bons caractères, et c'est Excel qui a changé leur sens en ouvrant le fichier. C'est le cas le plus courant, et toutes les solutions de ce guide partent de là.

Le deuxième indice, c'est de repérer quelles valeurs ont changé. Si les mots ordinaires, les petits nombres et la ponctuation semblent corrects, mais que les codes avec des zéros non significatifs les ont perdus, que les longs identifiants ont perdu leurs derniers chiffres, et que les grands nombres s'affichent en notation scientifique, vous êtes face à une devinette de type, et non à un problème de délimiteur ni à une corruption. Un problème de délimiteur met des lignes entières dans une seule colonne. Une corruption brouille tout ou fait disparaître des lignes. La devinette de type est chirurgicale : elle ne modifie que les valeurs qui ressemblent à des nombres, et laisse tout le reste intact. Si 00123 est devenu 123, 02138 est devenu 2138, et un identifiant de 16 chiffres se termine par un zéro qu'il n'avait pas avant, Excel a traité du texte comme des nombres, et cela vous indique à la fois la cause et la solution.

Le troisième contrôle permet de savoir si un sauvetage est encore possible. Si l'éditeur de texte affiche lui aussi les valeurs dépouillées, le fichier lui-même a déjà été réenregistré après la conversion, et les zéros ont peut-être disparu de cette copie. Ne paniquez pas pour autant, et surtout ne réenregistrez pas encore une fois par-dessus l'original. La section de sauvetage plus loin dans ce guide couvre exactement ce cas, y compris la seule situation où les chiffres sont vraiment irrécupérables : quand un long identifiant a été tronqué à 15 chiffres, les chiffres perdus ont disparu de cette copie, et seules les données sources peuvent les régénérer. Tant que vous n'avez pas vérifié, gardez le fichier original intact, travaillez sur une copie, et n'enregistrez jamais un fichier converti par-dessus le bon.

Pourquoi Excel devine : un fichier CSV ne contient aucun type

Pour comprendre pourquoi cela ne cesse de se produire, il faut connaître un fait sur le format CSV : un fichier CSV est du texte brut, sans en-tête qui indiquerait quelles valeurs sont des nombres, lesquelles sont du texte, et lesquelles sont des dates. Un fichier de tableur transporte ses types de cellules avec lui. Un fichier CSV ne transporte ni types ni mise en forme. Ce ne sont que des caractères, des virgules et des sauts de ligne. Quand un programme l'ouvre, il doit décider lui-même de ce que chaque valeur signifie, et les programmes ne décident pas tous de la même façon. Google Sheets et Python conservent les valeurs CSV sous forme de texte sauf instruction contraire, et c'est pourquoi le même fichier y semble correct. Excel, quand vous double-cliquez sur un fichier CSV, devine : tout ce qui ressemble à un nombre devient un nombre, tout ce qui ressemble à une date devient une date, et il ne vérifie pas si sa devinette était juste.

Cette devinette est tout le problème. Un nombre, par définition, n'a pas de zéros non significatifs : le nombre 123 et le code 00123 sont le même nombre, mais ce ne sont pas le même code. Un code postal, une référence, un matricule ou un indicatif téléphonique n'est pas une quantité. C'est une étiquette faite de chiffres, et ses zéros non significatifs font partie de l'étiquette, exactement comme les lettres d'un mot. Excel ne le sait pas. Il voit des chiffres, applique sa règle des nombres, et supprime les zéros, parce que pour un vrai nombre, les zéros ne portent aucune information. La même logique explique la deuxième victime : les nombres d'Excel ne conservent que 15 chiffres significatifs, donc un identifiant de 16 chiffres ou plus voit ses chiffres supplémentaires remplacés par des zéros. Le fichier n'a pas changé. C'est le lecteur qui a changé le sens des caractères.

Cela explique aussi pourquoi ce problème apparaît si souvent avec des fichiers convertis depuis JSON. JSON distingue les types : la chaîne "00123" et le nombre 123 sont des valeurs différentes, et une conversion de JSON vers CSV écrit la chaîne sous la forme des caractères 00123. La conversion est correcte. C'est l'ouverture qui ne correspond pas. Le convertisseur de cette page, par exemple, a été testé sur un échantillon contenant les codes 00123 et 00456, les codes postaux 02138 et 07477, et un identifiant de commande de 18 chiffres, et il a produit chaque valeur à l'identique dans le CSV, sans astuce de guillemets et sans chiffre perdu. Sachant que le décalage se situe à l'étape de l'ouverture, et non à celle de la conversion, vous savez où corriger : à l'import, avant qu'Excel ne devine, comme le montrent les sections suivantes.

Trois façons dont la devinette détruit les données, et comment les distinguer

La devinette de type détruit les données de trois façons distinctes, et il est important de les distinguer car certaines seulement sont réparables. La première, c'est la suppression des zéros non significatifs : 00123 devient 123, 02138 devient 2138. Les chiffres qui restent sont corrects, mais le code est désormais faux : un code postal qui a perdu son zéro désigne un autre endroit, une référence qui a perdu ses zéros ne correspondra plus au système de l'entrepôt, et un lecteur de code-barres peut rejeter le code raccourci. La deuxième, c'est la troncature de précision : tout identifiant de plus de 15 chiffres perd sa fin. Un identifiant de compte de 16 chiffres comme 1234567890123456 devient 1234567890123450, affiché sous la forme 1.23457E+15. Les derniers chiffres ne sont pas masqués, ils sont remplacés par des zéros, et l'identifiant désigne désormais un autre enregistrement, ou aucun enregistrement du tout.

La troisième façon est plus subtile, et elle piège les gens qui pensent avoir réglé le problème. L'affichage en notation scientifique ressemble à une perte de données, mais ce n'est pas encore le cas. Une valeur affichée sous la forme 1.23E+15 peut encore contenir tous ses chiffres en dessous si elle respecte la limite de 15 chiffres, et élargir la colonne ou changer le format les fait réapparaître. Mais si la valeur dépasse 15 chiffres, l'affichage est honnête : les chiffres sont vraiment perdus. Le test, c'est la barre de formule. Cliquez sur la cellule et lisez la barre de formule, pas l'affichage de la cellule. Si la barre de formule affiche la valeur complète, seul l'affichage doit être corrigé. Si la barre de formule affiche la valeur tronquée, les données elles-mêmes ont changé, et seule la section de sauvetage peut vous aider. Ne vous fiez jamais au seul affichage de la cellule pour les codes et les identifiants.

Le bloc de code ci-dessous montre les résultats exacts, obtenus en faisant tourner le vrai convertisseur de cette page sur un échantillon de trois lignes. La sortie CSV est identique octet par octet à l'entrée JSON pour chaque code, ce qui prouve que le convertisseur n'est pas le coupable. La colonne de droite montre ce qu'Excel fait de ces mêmes valeurs au double-clic, et c'est le comportement que ce guide corrige. Remarquez le schéma : le convertisseur préserve, Excel devine, et c'est dans la devinette que chaque chiffre se perd.

CSV file (from this page converter, verified):\nsku,zip,name,orderId\n00123,02138,Widget A,\n00456,07477,Widget B,\n00078,,Widget C,123456789012345678\n\nWhat Excel shows on double-click:\nsku -> 123, 456, 78 (leading zeros dropped)\nzip -> 2138, 7477 (leading zeros dropped)\norderId -> 1.23457E+17, stored as 123456789012345000 (last 3 digits replaced with zeros)

Remarquez ce que le tableau prouve : rien ne manque dans le fichier, et tout manque dans la vue Excel. C'est pourquoi la solution par import fonctionne si complètement. Quand vous dites à Excel qu'une colonne est de type Texte avant le chargement, il stocke les mêmes caractères sans aucune conversion, et chaque code retrouve son identité, sans retouche, sans rechercher-remplacer, et sans saisie manuelle. Si votre fichier correspond à ce schéma, passez la section qui démonte les idées reçues et allez directement à la solution par import. Vous n'avez pas un fichier abîmé. Vous avez un fichier mal lu.

Quatre solutions qui ne fonctionnent pas, et pourquoi on continue à les essayer

Avant les solutions qui fonctionnent, il vaut la peine d'écarter les quatre qui ne fonctionnent pas, car chacune fait perdre du temps et l'une d'entre elles aggrave les choses. La première, c'est de mettre les valeurs entre guillemets dans le CSV. Beaucoup de guides affirment qu'écrire "00123" entre guillemets protège les zéros. Ce n'est pas le cas, dans Excel. Excel retire les guillemets pendant l'import, puis applique la même devinette de nombre à la valeur qu'ils entourent, si bien que "00123" devient 123 exactement comme 00123 sans guillemets. Les guillemets contrôlent la façon dont les virgules à l'intérieur d'une valeur sont traitées, pas la façon dont Excel détermine le type de la valeur. Si quelqu'un vous a vendu un convertisseur qui met les codes entre guillemets pour les protéger, les guillemets protègent les virgules, pas les zéros.

La deuxième, c'est de formater la colonne en Texte après avoir ouvert le fichier. Cela change la façon dont les futures saisies seront traitées, mais cela ne restaure pas les chiffres déjà supprimés quand Excel a lu le fichier. Les zéros ont été écartés au moment de la lecture, et la mise en forme ne peut pas inventer des caractères qui ne sont plus là. La troisième, c'est le format personnalisé 00000, qui complète l'affichage jusqu'à cinq chiffres. Il ne fonctionne qu'en affichage, pour les codes de longueur fixe, et seulement quand les chiffres ont survécu : 123 s'affiche sous la forme 00123, mais la valeur stockée reste 123, donc tout export écrit 123, et toute recherche sur le vrai code échoue. Pire, il échoue silencieusement sur les codes de longueur variable, car un code de six chiffres complété à cinq chiffres reste inchangé, et un code de quatre chiffres complété à cinq gagne un zéro qu'il n'a jamais eu.

La quatrième, c'est l'astuce de l'apostrophe, qui consiste à taper une apostrophe avant le code, comme dans une cellule saisie sous la forme 00123 avec une apostrophe devant. Cela fonctionne pour les valeurs que vous saisissez à la main, car l'apostrophe dit à Excel de stocker la saisie sous forme de texte. Cela ne fonctionne pas pour un import CSV, car l'apostrophe fait alors partie du contenu du fichier : une cellule CSV contenant une apostrophe suivie de chiffres s'importe comme une valeur de texte qui commence littéralement par une apostrophe, ce qui casse les recherches et les exports. Gardez l'apostrophe pour les saisies manuelles, et utilisez la solution par import pour les fichiers. Savoir quelles solutions échouent vous épargne le piège le plus courant de tous : croire que le problème est résolu parce que l'affichage semble correct, alors que les valeurs stockées sont toujours fausses.

Solution 1 : importez le fichier et définissez les colonnes de codes sur Texte

C'est la solution à essayer en premier, car elle ne change rien à votre système, rien au fichier, et elle fonctionne sur n'importe quel CSV, quel que soit son délimiteur ou son encodage. Au lieu de double-cliquer sur le fichier, ouvrez d'abord Excel, puis importez le fichier par l'import guidé, où vous choisissez vous-même le type de chaque colonne. L'aperçu dans la boîte de dialogue d'import vous montre immédiatement si vous avez bien choisi : les codes s'y affichent avec leurs zéros exactement comme ils apparaîtront sur la feuille. Si l'aperçu montre encore des codes dépouillés, vous n'avez encore rien modifié, et vous pouvez ajuster les types de colonnes avant le chargement.

• ▸Ouvrez un classeur vierge dans Excel. Ne double-cliquez pas sur le fichier CSV.
• ▸Allez dans Données, puis À partir d'un fichier texte/CSV, et sélectionnez votre fichier.
• ▸Dans la boîte de dialogue d'aperçu, vérifiez le délimiteur et l'origine du fichier, puis cliquez sur Transformer les données au lieu de Charger, pour ouvrir l'éditeur Power Query.
• ▸Dans l'éditeur Power Query, repérez l'étape automatique Type modifié et supprimez-la, car c'est à cette étape que la devinette de nombre se produit.
• ▸Sélectionnez chaque colonne de codes, codes postaux, références, identifiants, indicatifs téléphoniques, et définissez le type de données sur Texte.
• ▸Cliquez sur Fermer et charger. Les codes arrivent sous forme de texte, avec chaque zéro non significatif et chaque chiffre intact.

Faites-en votre façon par défaut d'ouvrir les fichiers CSV, et pas seulement votre manœuvre de secours. Le double-clic est une devinette sur le délimiteur, l'encodage et le type de chaque colonne. L'import est un choix sur ces trois points, et ce choix prend environ une minute de plus. Sur Mac, le même chemin fonctionne via Données, puis À partir d'un fichier texte, avec les types de colonnes définis à l'étape d'import. Les outils qui lisent le CSV comme du texte brut, comme le module csv de Python, ne devinent jamais du tout, et c'est pourquoi un fichier qui semble cassé dans Excel se lit correctement dans un script. Cette différence est en soi un diagnostic : si un script affiche les zéros et qu'Excel ne les affiche pas, le fichier est correct et c'est Excel qui a mal deviné.

Solution 2 : désactivez la conversion automatique de données d'Excel (Microsoft 365 et Excel 2024)

Si vous ouvrez des fichiers CSV tous les jours, importer chaque fois devient fastidieux, et la solution durable consiste à changer ce qu'Excel devine par défaut. Les versions récentes d'Excel, Microsoft 365, Excel 2024, et leurs équivalents Mac, proposent un paramètre appelé conversion automatique de données, sous Fichier, puis Options, puis Données. Il énumère les conversions qu'Excel applique de lui-même, y compris la suppression des zéros non significatifs du texte numérique, la troncature des nombres à 15 chiffres, et la conversion des chaînes de lettres et de chiffres qui ressemblent à des dates ou à de la notation scientifique. Décochez les conversions dont vous ne voulez pas, et Excel laissera ces valeurs sous forme de texte lors des prochaines ouvertures, y compris les ouvertures par double-clic.

Deux mises en garde avant de vous reposer sur ce paramètre. D'abord, il ne change que le comportement futur. Il ne répare pas les cellules déjà converties, et il ne restaure pas les chiffres déjà supprimés. Un fichier ouvert la semaine dernière contient toujours les valeurs converties dans le classeur, et seule une nouvelle importation depuis le fichier original ramènera les codes. Ensuite, le paramètre vit sur votre machine, pas dans le fichier. Un collègue qui ouvre le même fichier sur une machine réglée par défaut verra toujours des codes dépouillés, et un fichier que vous envoyez n'emporte aucune protection avec lui. Considérez ce paramètre comme un confort pour votre propre machine, et la solution par import comme la méthode fiable pour les fichiers que vous partagez. Les guides compagnons sur le problème de la colonne unique et sur le problème d'encodage couvrent les deux autres devinettes qu'Excel fait à l'ouverture, le délimiteur et l'encodage, et ils sont liés dans les guides associés ci-dessous.

Solution 3 : pour les fichiers que vous produisez, gardez les codes en texte à la source

Si c'est vous qui produisez le CSV, la solution la plus solide consiste à rendre les données sources sans ambiguïté avant même qu'elles n'atteignent Excel. En JSON, cela signifie garder les codes sous forme de chaînes, et non de nombres : la chaîne "00123" se convertit en caractères 00123, tandis que le nombre 123 se convertit en 123, sans zéros à préserver. C'est une décision sur les données sources, pas un réglage du convertisseur, car aucun convertisseur ne peut inventer des zéros que le nombre source n'a jamais eus. Si votre système source stocke déjà un code postal sous forme de nombre, les zéros ont disparu avant la conversion, et seul le système source peut les restaurer, par exemple en réexportant le code sous forme de chaîne de largeur fixe.

Pour les valeurs qui ont déjà perdu leurs zéros mais dont la longueur est fixe, il existe une reconstruction légitime : la fonction TEXTE. Si chaque code d'une colonne fait cinq chiffres, =TEXTE(A2;"00000") reconstruit l'affichage et la valeur texte à partir du nombre dépouillé, car les chiffres manquants sont tous des zéros et leur nombre est connu. Copiez les résultats et collez-les en valeurs pour les figer. Mais cela ne fonctionne que quand la longueur est fixe et que le seul dommage est la suppression de zéros non significatifs. Cela ne peut pas reconstruire un long identifiant tronqué, car les chiffres perdus n'étaient pas des zéros, c'étaient des chiffres inconnus remplacés par des zéros, et aucune formule ne peut les deviner. Si vos identifiants varient en longueur ou dépassent 15 chiffres, ne complétez pas, régénérez depuis la source.

Sauvez un fichier déjà enregistré avec des codes dépouillés

Jusqu'ici, chaque solution supposait que le fichier sur le disque est toujours correct et que seule la vue Excel est fausse. Mais il arrive que la version dépouillée ait déjà été enregistrée, et la question devient alors de savoir si les codes originaux peuvent encore être récupérés depuis la copie enregistrée. La réponse dépend exactement de ce que l'enregistrement a fait, et il faut distinguer deux cas. Dans le premier cas, le fichier sur le disque contient toujours les caractères originaux, et seul l'affichage du classeur est faux. C'est le cas que le test de l'éditeur de texte détecte : l'éditeur affiche les zéros, donc rien n'est perdu, et la solution 1 répare la vue. Dans le deuxième cas, le fichier sur le disque contient désormais les valeurs dépouillées elles-mêmes, parce que quelqu'un l'a ouvert dans Excel, a vu les codes raccourcis, et l'a réenregistré en CSV, écrivant ainsi les valeurs converties dans le fichier.

Le deuxième cas n'est récupérable que dans des circonstances étroites. Si chaque code a une longueur fixe et que le seul dommage est la suppression de zéros non significatifs, la fonction TEXTE de la solution 3 les reconstruit, car les caractères manquants sont connus pour être des zéros. Travaillez sur une copie, jamais sur la seule version existante, et vérifiez le résultat dans un éditeur de texte avant de l'ouvrir à nouveau dans Excel. Si le dommage est une troncature de précision, un identifiant de plus de 15 chiffres dont la fin a été remplacée par des zéros, les chiffres originaux ont disparu de cette copie. Aucun décodage, aucune mise en forme, aucune formule ne peut récupérer des chiffres remplacés par des zéros de remplissage, car ces zéros ne portent aucune information sur les chiffres qu'ils ont remplacés. Dans ce cas, arrêtez de réparer la copie et régénérez le fichier depuis sa source : réexportez-le depuis la base de données, l'outil, ou le JSON dont il provient, et cette fois ouvrez-le avec la solution 1. Et quoi que vous fassiez, gardez la copie abîmée de côté jusqu'à ce que le fichier régénéré soit vérifié. Supprimer la seule copie avant d'avoir vérifié le remplacement, c'est ainsi qu'un problème récupérable devient un jeu de données perdu.

Ce que cela signifie pour les fichiers issus du convertisseur de cette page

Le convertisseur de cette page produit exactement le type de fichier dont parle ce guide, il vaut donc la peine d'énoncer son comportement sans détour. Le téléchargement préserve les codes exactement comme le JSON les contient. Cela a été vérifié sur le vrai code, et non supposé : le moteur de conversion a été testé sur un échantillon de trois lignes contenant les codes 00123, 00456 et 00078, les codes postaux 02138 et 07477, et l'identifiant de commande de 18 chiffres 123456789012345678, et il a produit chaque valeur à l'identique dans le CSV, avec les codes sans guillemets car ils ne contiennent aucun délimiteur, et le long identifiant intact. Donc si votre fichier converti affiche des codes dépouillés dans Excel, la conversion n'a rien abîmé. Le fichier est correct, et c'est Excel qui a deviné les types au double-clic.

Cela vous laisse deux options nettes pour les fichiers convertis. La première, c'est la voie de l'import : ouvrez le fichier téléchargé avec Données, puis À partir d'un fichier texte/CSV, cliquez sur Transformer les données, définissez chaque colonne de codes sur Texte, et chargez. Les codes se liront correctement, et vous n'avez rien changé au fichier, qui reste donc valide pour tous les autres outils. La deuxième, c'est le paramètre de conversion automatique de la solution 2, pour votre propre machine. Ne reconvertissez pas les données pour corriger un problème d'affichage lié à la devinette de type, et ne faites pas passer la sortie convertie par un tableur pour la réenregistrer, car cet aller-retour peut introduire exactement les décalages de délimiteur, d'encodage et de type que ce guide et ses compagnons existent pour prévenir. Corrigez l'ouverture, pas les données.

Un dernier détail du convertisseur compte ici. Le convertisseur vous laisse choisir le délimiteur avant le téléchargement, et ce choix est indépendant de la devinette de type. Un fichier peut avoir le bon délimiteur et des codes dépouillés en même temps, ou les bons codes et le mauvais délimiteur, ou les deux faux à la fois. Si votre fichier converti s'ouvre dans une seule colonne et que les codes semblent faux, corrigez les deux réglages dans le même import : choisissez le délimiteur sélectionné au moment de la conversion, et définissez les colonnes de codes sur Texte. Le guide compagnon sur le problème de la colonne unique couvre la moitié délimiteur en détail, et le guide sur l'encodage couvre la moitié caractères, et les deux sont liés dans les guides associés ci-dessous.

Liste de prévention : exportez vos codes pour que personne n'ait à les corriger

La devinette de type est un décalage entre celui qui écrit et celui qui lit, donc la prévention consiste à faire en sorte que celui qui écrit déclare ce que sont les valeurs, d'une façon que le lecteur respectera. Passez en revue cette liste quand vous produisez un CSV, et la prochaine personne qui l'ouvrira n'aura pas besoin de ce guide. D'abord, gardez les codes sous forme de chaînes à la source. Si vos données contiennent des codes postaux, des références ou des identifiants, stockez-les en texte dans le système source, car un type nombre supprime les zéros avant même tout export. Ensuite, si le public utilise Excel, dites-lui comment ouvrir le fichier : une note d'une ligne indiquant d'importer avec les colonnes de codes définies sur Texte prévient tout le problème, et cela ne coûte rien de la joindre au fichier.

Troisièmement, n'enregistrez jamais un fichier sauvé par-dessus l'original tant que vous n'avez pas vérifié le sauvetage dans un éditeur de texte. Un enregistrement depuis Excel réécrit les types, les délimiteurs et l'encodage avec les paramètres par défaut d'Excel, ce qui peut réintroduire le décalage pour le lecteur suivant, ou transformer un problème d'affichage en véritable perte de données. Quatrièmement, quand vous recevez un fichier, ouvrez-le d'abord dans un éditeur de texte si quelque chose semble anormal, et confirmez les codes avant de laisser un tableur l'écraser. Et cinquièmement, conservez les données sources. Un CSV est un instantané aplati, pas les données elles-mêmes, donc si un sauvetage tourne mal, la source permet de réexporter proprement au lieu de réparer une copie abîmée. La plupart des histoires d'horreur sur les codes se terminent par quelqu'un qui découvre trop tard que le CSV abîmé était la seule copie. Ne laissez pas cela arriver à votre fichier.

Guides associés

• Votre CSV s'ouvre dans une seule colonne dans Excel : pourquoi et comment le corriger (Guide 2026) →
• Pourquoi votre CSV affiche des caractères spéciaux illisibles dans Excel, et comment corriger l'encodage (Guide 2026) →
• Comment convertir JSON en CSV : 3 méthodes fiables (guide 2026) →
• Pourquoi Excel change les dates de votre CSV, et comment les conserver (Guide 2026) →
• Pourquoi l'enregistrement de votre CSV dans Excel le modifie, et comment protéger l'original (Guide 2026) →
• Fichier CSV trop volumineux pour Excel : pourquoi Excel ne l'ouvre pas et que faire à la place (Guide 2026) →

Questions fréquentes