Pourquoi l'enregistrement de votre CSV dans Excel le modifie, et comment protéger l'original (Guide 2026)

Diagnostiquer en 30 secondes : comparer le fichier avant et après l'enregistrement

La première chose à établir quand un fichier CSV semble différent après un passage dans Excel est de savoir si le fichier lui-même a changé, ou si seul l'affichage d'Excel vous trompe, car les deux cas appellent des corrections très différentes. Voici le test de 30 secondes. Avant d'ouvrir un CSV dans Excel, faites-en une copie. Après l'enregistrement depuis Excel, ouvrez les deux fichiers dans un éditeur de texte brut, le Bloc-notes sous Windows ou TextEdit en mode texte brut sur Mac, et comparez-les côte à côte. Si la copie enregistrée montre des délimiteurs différents, des caractères différents, des zéros supprimés ou des dates reformattées, le fichier a changé. Si les deux fichiers correspondent caractère pour caractère, seul l'affichage d'Excel vous induisait en erreur, et le fichier est sain.

Le deuxième indice est l'emplacement des changements. Un enregistrement qui a réécrit le fichier modifie les valeurs dans tout le fichier selon un motif régulier : chaque délimiteur virgule est devenu un point-virgule, chaque nom accentué s'est transformé en points d'interrogation ou en paires de lettres étranges, chaque code a perdu ses zéros initiaux. Un dommage isolé sur une seule ligne, ou une seule ligne manquante, pointe vers autre chose, comme une erreur de saisie ou un export tronqué. Des changements réguliers, sur tout le fichier, sont la signature d'un enregistrement qui a réécrit le fichier avec les réglages par défaut d'Excel, et ils vous disent exactement quel réglage corriger : le paramètre de séparateur, le choix d'encodage, ou la façon dont le fichier a été ouvert au départ.

Le troisième contrôle décide si un sauvetage est encore possible, et c'est celui que l'on oublie le plus souvent. Si vous possédez encore la copie d'avant Excel, ou la source dont le CSV provient, rien n'est perdu : régénérez le fichier ou réimportez-le depuis la bonne copie et le problème est réglé. Si le fichier enregistré a écrasé la seule copie existante, le sauvetage dépend des sauvegardes, de l'historique des versions, ou d'un nouvel export depuis le système source, ce que la section de sauvetage couvre. Tant que vous n'avez pas vérifié, n'enregistrez pas une deuxième fois, ne refermez pas le classeur sur le même fichier, et ne supprimez pas la copie enregistrée : une copie abîmée qui conserve l'essentiel des données vaut mieux comme preuve qu'aucune copie du tout.

BEFORE (as exported, comma delimited, UTF-8):
code,zip,name,shipDate,note
00123,02138,Zoë Café,2026-03-04,fragile; handle with care
00456,07477,Müller,2026-04-03,gift

AFTER (saved from Excel on a European-locale machine):
code;zip;name;shipDate;note
123;2138;Zoë Café;03.04.2026;fragile; handle with care
456;7477;Müller;03.04.2026;gift

What changed: commas became semicolons, leading zeros vanished,
dates were reformatted, and one note split into two columns.

Remarquez ce que cet exemple prouve : aucun réglage unique n'a causé tout cela. Le délimiteur a changé à cause des paramètres régionaux de la machine, les zéros ont disparu à cause de la devinette de type à l'ouverture, et les dates ont changé parce qu'Excel les a stockées comme des dates et les a réécrites dans son propre format d'affichage. Un enregistrement n'introduit pas une seule erreur. Il fige d'un coup toutes les suppositions qu'Excel a faites à l'ouverture, et c'est pourquoi l'enregistrement semble si destructeur alors que chaque supposition prise isolément paraissait anodine à l'écran.

Pourquoi un enregistrement n'est pas une copie : ce qu'Excel écrit réellement sur le disque

Pour comprendre pourquoi l'enregistrement modifie un CSV, il faut retenir un fait sur ce qu'Excel fait quand il ouvre le fichier. Excel ne conserve pas le fichier sous forme de texte. Il analyse le texte en cellules, décide d'un type pour chaque cellule, applique vos paramètres régionaux, et vous montre une grille. Ce que vous voyez est l'interprétation du fichier par Excel, pas le fichier lui-même. À l'enregistrement, Excel réécrit la grille en texte. Le fichier enregistré reflète donc la grille, avec toutes ses suppositions intégrées, et non les caractères d'origine. L'aller-retour du texte vers la grille puis vers le texte est l'endroit où se produit chaque changement décrit dans ce guide.

La première chose que la réécriture abandonne est tout ce qui n'est pas une valeur de cellule. Un fichier CSV ne contient que des lignes et des colonnes de valeurs, rien d'autre, donc quand Excel en enregistre un, il ne conserve que le texte et les valeurs tels qu'ils s'affichent dans les cellules de la feuille active. Les graphiques, les images, les couleurs de cellules, le gras, les cellules fusionnées, les règles de validation et les liens hypertexte ne survivent pas, parce que le format n'a aucun endroit pour les stocker. Les formules sont remplacées par le résultat qu'elles calculent actuellement, donc une cellule contenant une formule qui calcule un total s'enregistre comme le nombre total, pas comme la formule. C'est généralement ce que l'on veut quand on exporte vers un autre système, mais cela signifie que le CSV enregistré est un instantané d'un moment donné, pas un tableur fonctionnel, et que sa réouverture ne ramènera jamais les formules.

La deuxième chose que la réécriture abandonne est chaque feuille sauf celle que vous regardiez. Un classeur peut contenir beaucoup de feuilles, mais un fichier CSV est un seul tableau, donc Excel n'enregistre que la feuille active et vous avertit que les autres feuilles ne seront pas enregistrées. On clique sur cet avertissement tous les jours sans le lire, et le fichier enregistré ne contient alors qu'une feuille de données pendant que le reste demeure dans le classeur non enregistré. Si vous fermez le classeur sans l'enregistrer dans un format de tableur, les autres feuilles sont perdues. L'avertissement est la façon dont Excel vous dit, clairement, que l'enregistrement entraîne une perte, et la réaction sûre consiste à conserver le classeur enregistré séparément dans son propre format avant d'exporter quoi que ce soit en CSV.

La troisième chose que la réécriture modifie est les valeurs elles-mêmes, parce qu'Excel enregistre les valeurs telles qu'elles s'affichent, et non telles qu'elles sont stockées. Une cellule qui stocke un nombre précis que vous avez formaté avec deux décimales s'enregistre avec l'affichage à deux décimales, pas avec la valeur complète stockée. Une date stockée sous forme de numéro de série s'enregistre dans le format d'affichage de votre machine. Un code qu'Excel a pris pour un nombre s'enregistre comme ce nombre, sans ses zéros initiaux. Rien de tout cela n'est un bogue. C'est ce que signifie enregistrer une grille en texte. Mais cela veut dire que le fichier enregistré peut différer de l'original de façons invisibles jusqu'à ce qu'un autre programme le lise, et c'est pourquoi vérifier le fichier enregistré dans un éditeur de texte compte davantage que le vérifier à l'écran.

L'écrasement silencieux : comment Ctrl+S transforme une supposition en fichier

L'enregistrement le plus destructeur n'est pas Enregistrer sous. C'est le simple Ctrl+S, ou l'invite d'enregistrement à la fermeture, sur un fichier CSV que vous vouliez seulement consulter. Vous double-cliquez sur un CSV pour vérifier une valeur, vous corrigez une faute de frappe, vous appuyez sur Ctrl+S par habitude, et Excel réécrit tout le fichier avec ses propres réglages par défaut. Vous avez modifié une cellule. Excel a réécrit chaque ligne. Cette asymétrie est le coeur du problème : un enregistrement est une opération sur tout le fichier, pas un correctif appliqué à la cellule touchée, et chaque supposition faite par Excel à l'ouverture devient définitive dans la même frappe.

Excel vous avertit, deux fois, et les deux avertissements se balaient facilement. Le premier avertissement indique que le fichier peut contenir des fonctionnalités incompatibles avec le CSV, ce qui est la façon dont Excel vous dit que la mise en forme et les feuilles supplémentaires seront perdues. Le second, dans certaines versions, demande s'il faut conserver le format actuel. Les personnes qui voient ces boîtes de dialogue tous les jours cliquent sur Conserver le format actuel sans lire, parce que la boîte ressemble à une confirmation de routine plutôt qu'à un avertissement de perte de données. Il vaut la peine de ralentir pour exactement ces deux boîtes de dialogue. Elles sont le dernier moment où le fichier d'origine existe encore intact, et choisir de ne pas enregistrer, ou choisir Enregistrer sous avec un nouveau nom, ne coûte rien et préserve tout.

L'aller-retour est ce qui rend l'écrasement si difficile à annuler. L'ouverture devine les types, et l'enregistrement réécrit les suppositions, donc la deuxième ouverture part de valeurs déjà devinées et devine à nouveau par dessus. Un code qui a perdu ses zéros à la première ouverture ne peut pas les retrouver à la deuxième, parce que les zéros ne figurent plus dans le fichier pour qu'un programme puisse les lire. Une date dont le jour et le mois ont été inversés à la première ouverture s'inverse à nouveau ou reste inversée, parce que le fichier contient désormais la date inversée comme si c'était la vérité. Chaque aller-retour dans Excel ne peut que perdre de l'information, jamais la restaurer, et c'est pourquoi la règle de ce guide est absolue : ne laissez jamais Excel enregistrer par dessus la seule copie d'un fichier CSV.

Changement 1 : le séparateur qui bascule, quand les virgules deviennent des points-virgules

Le changement d'enregistrement le plus visible est la bascule du séparateur : un fichier délimité par des virgules revient délimité par des points-virgules, et le programme suivant qui le lit met chaque ligne dans une seule colonne ou rejette le fichier. La cause est le séparateur de liste de votre machine, un paramètre régional qu'Excel utilise chaque fois qu'il écrit un fichier CSV. En Amérique du Nord et au Royaume-Uni, le séparateur de liste est la virgule, donc un CSV enregistré reste délimité par des virgules. Dans une grande partie de l'Europe, la virgule est le symbole décimal, donc le séparateur de liste est le point-virgule, et Excel écrit des points-virgules à la place des virgules. L'extension reste .csv dans les deux cas, donc rien dans le nom du fichier n'avertit le lecteur suivant que le délimiteur a changé.

C'est le même problème de délimiteur que celui traité dans le guide compagnon sur le problème de la colonne unique, mais la direction de l'enregistrement mérite son propre avertissement, parce que la correction est différente. Quand un fichier s'ouvre dans une seule colonne, vous corrigez l'ouverture. Quand un fichier s'enregistre avec le mauvais délimiteur, vous corrigez l'export : dans Excel, allez dans Fichier, puis Options, puis Options avancées, décochez Utiliser les séparateurs système, et définissez le séparateur décimal sur un point et le séparateur de milliers sur une virgule, ce qui fait qu'Excel utilise la virgule comme séparateur de liste. Remettez le réglage en place après l'export si vous n'en avez besoin que pour un fichier, parce que ce réglage affecte chaque CSV qu'Excel écrit tant qu'il est modifié. Sur Mac, le même réglage se trouve dans Réglages Système, sous Général, puis Langue et région, dans les séparateurs de nombres.

Il existe aussi un contrôle plus simple qui détecte ce changement avant qu'il ne cause des dégâts. Ouvrez le fichier enregistré dans un éditeur de texte et regardez la première ligne. Si l'en-tête montre des points-virgules là où l'original montrait des virgules, le délimiteur a basculé, et vous devez réexporter avec le réglage ci-dessus au lieu d'envoyer le fichier. Un éditeur de texte vous montre la vérité en un coup d'oeil, alors qu'Excel la cache complètement, parce qu'Excel lit les deux délimiteurs dans la même grille. Ne jugez jamais un CSV enregistré à son apparence dans Excel. Jugez-le à son apparence en texte brut.

Changement 2 : la dégradation de l'encodage, quand les lettres accentuées se cassent

Le deuxième changement d'enregistrement est plus discret et plus vicieux : la dégradation de l'encodage. Excel propose deux types d'enregistrement CSV qui semblent presque identiques, et choisir le mauvais corrompt chaque caractère non anglais du fichier. CSV UTF-8 écrit le fichier en UTF-8, ce qui couvre les lettres accentuées, les trémas et les écritures non latines. Le CSV simple écrit le fichier dans l'encodage historique de votre système, qui sur beaucoup de machines Windows ne peut pas du tout représenter ces caractères, donc ils reviennent sous forme de points d'interrogation ou de lettres fausses. Les deux options se côtoient dans la liste Enregistrer sous, et l'option simple est celle que l'on choisit par habitude.

La règle est simple : choisissez toujours CSV UTF-8 quand vous enregistrez depuis Excel, sauf si le programme destinataire exige explicitement le format historique. Et même alors, vérifiez le résultat dans un éditeur de texte, parce que la perte liée à l'encodage historique est à sens unique : une fois qu'une lettre accentuée a été remplacée par un point d'interrogation dans le fichier enregistré, aucune réimportation ne peut récupérer la lettre d'origine, parce que le fichier enregistré ne la contient plus. Le guide compagnon sur l'encodage couvre le diagnostic complet, y compris l'astuce de la marque d'ordre des octets qui fait deviner UTF-8 à Excel au double-clic, mais la règle d'enregistrement tient seule : l'encodage choisi au moment de l'enregistrement est l'encodage que le lecteur suivant reçoit, et le mauvais choix abîme chaque valeur non ASCII d'un coup.

Un dernier détail d'encodage compte pour les fichiers de cette page. Le téléchargement du convertisseur est en UTF-8 brut, sans marque d'ordre des octets, ce qui est la forme la plus propre pour la plupart des outils, mais cela signifie qu'un double-clic dans Excel peut mal interpréter les lettres accentuées sur certaines machines Windows. C'est un problème d'ouverture, traité dans le guide sur l'encodage, pas un problème d'enregistrement, et cela ne change pas la règle d'enregistrement. Quelle que soit l'encodage source, enregistrez depuis Excel en CSV UTF-8, et vérifiez dans un éditeur de texte que les noms accentués se lisent encore correctement avant d'envoyer le fichier.

Changement 3 : la réécriture des types, quand les suppositions deviennent les données

Le troisième changement d'enregistrement est la réécriture des types, et ce sont en réalité trois problèmes compagnons qui arrivent ensemble, parce que le même aller-retour ouverture puis enregistrement réécrit chaque supposition faite par Excel. Les zéros initiaux disparaissent, parce qu'Excel a lu les codes comme des nombres à l'ouverture et réécrit des nombres sans eux. Les dates sont reformattées ou inversées, parce qu'Excel les a stockées comme des numéros de série et les réécrit dans son propre format d'affichage. Les longs identifiants perdent leurs derniers chiffres, parce qu'Excel ne conserve que quinze chiffres significatifs et écrit des zéros pour le reste. Chacun de ces problèmes possède son propre guide compagnon avec ses propres corrections, et cet article ne répète pas ces corrections, parce que la leçon sur l'enregistrement est la même pour les trois : le dommage a eu lieu à l'ouverture, et l'enregistrement est ce qui l'a rendu définitif.

Ce qui vaut la peine d'être énoncé ici est le test qui sépare un problème d'affichage d'un problème d'enregistrement. Ouvrez le fichier dans un éditeur de texte. Si les codes, les dates et les identifiants s'y lisent correctement, le fichier est encore bon et seule la vue Excel est fausse : fermez sans enregistrer et réimportez proprement. Si l'éditeur de texte montre des zéros supprimés, des dates inversées ou des identifiants tronqués, l'enregistrement a déjà réécrit le fichier, et la section de sauvetage est votre seule voie. Ce test prend dix secondes, et c'est l'habitude la plus utile de tout ce guide, parce qu'il vous dit si vous possédez encore un bon fichier ou seulement un fichier abîmé.

Il vaut aussi la peine de savoir ce qui n'est pas réécrit. Les mots simples, les petits nombres qui ne nécessitent aucune devinette, et les valeurs qu'Excel a laissées en texte survivent tous à un enregistrement sans changement, et c'est pourquoi un fichier enregistré peut sembler presque correct tout en étant faux dans exactement les colonnes qui comptent : les codes, les dates et les identifiants. Vérifier au hasard une ligne ordinaire ne prouve rien. Vérifiez spécifiquement les colonnes sensibles : la colonne des codes, la colonne des dates et la colonne des longs identifiants, dans un éditeur de texte, après chaque enregistrement, avant d'envoyer le fichier où que ce soit.

Quatre solutions qui ne fonctionnent pas après un mauvais enregistrement

Avant les solutions qui fonctionnent, il vaut la peine d'écarter les quatre solutions qui ne fonctionnent pas, parce que chacune fait perdre du temps et que l'une d'elles aggrave les choses. La première est de reformatter le fichier enregistré après coup. Changer le format d'une colonne change la façon dont les valeurs stockées s'affichent, mais cela ne peut pas restaurer des caractères que l'enregistrement a déjà supprimés. Un code enregistré comme 123 ne peut pas retrouver ses zéros en formatant la colonne en Texte, parce que le fichier contient désormais 123 et rien d'autre. Le formatage est de l'affichage. Le texte enregistré est la donnée, et les changements d'affichage ne touchent jamais la donnée.

La deuxième est d'appuyer sur Annuler après l'enregistrement. Annuler inverse les modifications à l'intérieur du classeur ouvert, mais cela ne désécrit pas un fichier déjà enregistré sur le disque. Une fois l'enregistrement terminé, le disque contient le fichier réécrit, et aucune annulation dans le classeur ne ramène les caractères d'origine. La troisième est de mettre les valeurs entre guillemets dans le fichier enregistré. 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 d'une valeur, et Excel retire les guillemets à l'importation et devine le type de toute façon, donc ajouter des guillemets à un fichier abîmé ne change rien au dommage. La quatrième est le rechercher-remplacer sur tout le fichier enregistré pour réparer les dates inversées ou les zéros supprimés à la main. Cela ne fonctionne que si chaque ligne a subi le même changement, ce qui n'est jamais le cas pour des colonnes mélangées, donc un remplacement global corrompt les lignes qui étaient correctes tout en réparant celles qui étaient fausses.

Savoir quelles solutions échouent vous épargne le piège le plus courant de tous : croire que le problème est résolu parce que le classeur à l'écran semble correct, alors que le fichier sur le disque est encore faux. L'écran n'est pas le fichier. L'éditeur de texte est le fichier. Chaque réparation dans la suite de ce guide part de cette distinction, et chaque vérification se termine par elle.

Solution 1 : ne jamais enregistrer par dessus l'original, garder une copie maîtresse

C'est la solution à essayer en premier, parce qu'elle ne coûte rien, ne change rien à votre système, et rend récupérable chaque autre erreur de ce guide. Gardez le fichier CSV d'origine intact, et effectuez tout votre travail Excel sur une copie. Le flux de travail est délibérément ennuyeux : quand un CSV arrive, enregistrez-le dans un dossier appelé originaux et n'ouvrez jamais cette copie dans Excel. Copiez-le dans un dossier de travail, et ouvrez la copie de travail. Si un enregistrement tourne mal, supprimez la copie de travail, copiez à nouveau l'original, et recommencez. Aucun sauvetage, aucune réparation, aucune donnée perdue, parce que le bon fichier n'a jamais été en danger.

Si vous produisez vous-même le CSV, gardez le document maître au format tableur et traitez le CSV comme un export, pas comme le document. Travaillez dans le classeur, enregistrez le classeur, et exportez un CSV frais chaque fois que vous en avez besoin, avec un nom versionné comme clients-2026-11-05.csv pour qu'un export ne remplace jamais silencieusement un précédent. Un CSV est un instantané aplati, pas la donnée elle-même, donc le classeur maître, ou mieux encore la base de données ou le JSON dont provient la donnée, est ce qu'il faut protéger. Dès qu'un CSV devient la seule copie de vos données, chaque enregistrement Excel devient un risque pour la seule copie, et c'est la situation que ce guide existe pour empêcher.

• ▸Enregistrez chaque CSV entrant dans un dossier originaux avant de l'ouvrir où que ce soit.
• ▸Travaillez uniquement sur une copie, et nommez les exports avec une date pour qu'ils n'écrasent jamais rien silencieusement.
• ▸Gardez le classeur maître enregistré au format tableur, séparément de tout export CSV.
• ▸Si un enregistrement tourne mal, jetez la copie de travail et recommencez depuis l'original.

Cette règle vous protège aussi contre l'avertissement multi-feuilles. Si votre classeur contient plusieurs feuilles et que vous en exportez une en CSV, le classeur lui-même reste intact dans son propre format, et vous pouvez exporter chaque feuille séparément quand vous en avez besoin. L'export CSV est un instantané à sens unique pour un usage précis, et le classeur demeure le document vivant. On perd des feuilles non pas parce que le CSV est dangereux, mais parce qu'on a fermé le classeur sans l'enregistrer après l'export, et l'habitude de la copie maîtresse rend cette erreur impossible.

Solution 2 : modifier en sécurité, dans un éditeur de texte ou par une importation correcte

La deuxième solution concerne la façon de modifier, et elle comporte deux branches selon l'ampleur du travail. Pour une petite modification, changer une valeur ou deux, corriger une faute de frappe, rectifier une ligne, n'ouvrez pas du tout le fichier dans Excel. Ouvrez-le dans un éditeur de texte, effectuez la modification, et enregistrez depuis l'éditeur. Un éditeur de texte réécrit exactement les caractères que vous voyez, sans devinette de type, sans bascule de délimiteur et sans changement d'encodage, tant que vous conservez le même encodage à l'enregistrement. Pour une correction d'une ligne, l'éditeur de texte n'est pas un contournement. C'est l'outil correct, et il est plus rapide qu'Excel pour ce travail.

Pour une grosse modification, où vous avez besoin de trier, de filtrer ou de formules, importez le fichier correctement au lieu de double-cliquer dessus. Ouvrez un classeur vierge, allez dans Données, puis À partir d'un texte/CSV, et dans l'aperçu définissez le délimiteur, l'encodage et le type de chaque colonne sensible avant le chargement : les codes et les identifiants en Texte, les dates en Texte ou en Date avec les paramètres régionaux de la source. Faites votre travail, puis exportez avec Enregistrer sous, choisissez CSV UTF-8, donnez à l'export un nouveau nom pour qu'il ne puisse pas écraser l'original, et vérifiez le résultat dans un éditeur de texte avant de l'envoyer. L'étape d'importation est celle où vous prenez le contrôle des trois suppositions d'un coup, et la vérification dans l'éditeur de texte est celle où vous prouvez que l'export est propre.

Une autre option de modification sûre mérite d'être mentionnée : modifier la donnée à sa source plutôt que de modifier le CSV. Si le CSV provient d'un JSON, corrigez le JSON et convertissez à nouveau, ce qui produit un fichier propre sans aucun dommage d'aller-retour. S'il provient d'une base de données, réexportez depuis la base de données. Régénérer depuis la source est toujours plus propre que réparer un fichier déjà passé par un tableur, parce que la source contient les vraies valeurs et que l'export ne contient qu'un instantané de ces valeurs.

Solution 3 : vérifier avant d'envoyer, le contrôle de deux minutes dans l'éditeur de texte

La troisième solution est une habitude, pas un réglage : vérifiez chaque CSV enregistré dans un éditeur de texte avant de l'envoyer où que ce soit, en suivant une courte liste de contrôle qui prend environ deux minutes. Ouvrez le fichier enregistré et l'original côte à côte, et vérifiez cinq points. Premièrement, le délimiteur : la ligne d'en-tête utilise-t-elle le même séparateur dans les deux fichiers. Deuxièmement, le nombre de lignes : le fichier enregistré contient-il le même nombre de lignes, en gardant à l'esprit que les valeurs contenant des sauts de ligne peuvent s'étendre sur plusieurs lignes. Troisièmement, les colonnes sensibles : les codes portent-ils encore leurs zéros initiaux, les dates se lisent-elles encore comme la source les a écrites, les longs identifiants contiennent-ils encore tous leurs chiffres. Quatrièmement, l'encodage : les noms accentués se lisent-ils encore correctement, sans points d'interrogation ni paires de lettres étranges. Cinquièmement, les guillemets : les valeurs qui contiennent le délimiteur sont-elles encore entourées de guillemets, pour rester dans une seule colonne.

Si un contrôle échoue, n'envoyez pas le fichier et n'essayez pas de le corriger dans le tableur. Revenez à l'original, corrigez le réglage qui a causé l'échec, et exportez à nouveau. Un contrôle raté coûte peu quand l'original existe encore et coûte cher quand il n'existe plus, et c'est pourquoi ce contrôle doit avoir lieu avant l'envoi, pas après une plainte. La réaction la plus courante face à un contrôle raté est de rouvrir le fichier enregistré dans Excel pour le corriger, ce qui lance un nouvel aller-retour et ajoute généralement de nouveaux dégâts. Corrigez l'export, pas le fichier exporté.

Intégrez le contrôle à l'export lui-même, pas comme une corvée séparée. Enregistrer sous, ouvrir dans un éditeur de texte, effectuer les cinq contrôles, puis envoyer. Après quelques exports, le contrôle devient automatique, et les fichiers que vous envoyez cessent de revenir avec des plaintes sur des zéros manquants, des dates inversées ou des mises en page en une seule colonne. Le contrôle est aussi votre preuve : si un destinataire signale un problème plus tard, vous pouvez comparer le fichier envoyé avec l'original et montrer exactement où le changement s'est produit, au lieu de deviner.

Récupérer un fichier déjà enregistré par dessus

Parfois le conseil arrive trop tard, et le fichier enregistré a déjà écrasé la seule copie. Un sauvetage est possible dans certains cas, et la réponse honnête est que cela dépend de ce qui existe en plus du fichier abîmé. D'abord, vérifiez les sauvegardes automatiques : OneDrive et SharePoint conservent un historique des versions pour les fichiers qui y sont stockés, donc faites un clic droit sur le fichier et cherchez les versions précédentes avant toute autre action. L'historique des fichiers de Windows et Time Machine sur Mac conservent leurs propres copies si ces fonctions étaient activées. Les pièces jointes d'e-mails, les envois dans des messageries et les lecteurs partagés contiennent souvent une copie antérieure du même fichier, envoyée avant le mauvais enregistrement, et cette copie est souvent le sauvetage le plus propre disponible.

Ensuite, s'il n'existe aucune copie antérieure, vérifiez si le dommage est assez uniforme pour être inversé. Si chaque date a été inversée selon une seule convention et que chaque jour d'origine était inférieur ou égal à 12, une formule peut les inverser à nouveau, et si chaque code a perdu le même nombre de zéros, ces zéros peuvent être restaurés par le formatage, mais seulement quand la perte était uniforme sur toute la colonne. Travaillez sur une copie, jamais sur la seule version, et vérifiez le résultat par rapport à un enregistrement connu avant de lui faire confiance. Si le dommage est mélangé, certaines lignes inversées, d'autres restées en texte, certains codes devenus des dates, les caractères d'origine ont disparu de cette copie d'une façon qu'aucune formule ne peut démêler, parce qu'un nombre enregistré ne consigne pas ce qu'il était auparavant.

Troisièmement, et c'est le plus fiable, 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 une importation correcte et ne l'enregistrez jamais par dessus. Si la source est un JSON, le convertisseur de cette page produit un CSV frais à partir du JSON d'origine en quelques secondes, avec chaque valeur exactement telle qu'elle est écrite, et ce fichier frais remplace entièrement le fichier abîmé. Quelle que soit la voie choisie, gardez la copie abîmée de côté jusqu'à ce que le remplacement soit vérifié dans un éditeur de texte. Supprimer la seule copie avant de vérifier le remplacement est la façon dont un problème récupérable devient un ensemble de données perdu.

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

Le convertisseur de cette page produit exactement le type de fichier dont traite ce guide, donc il vaut la peine d'énoncer son comportement clairement, vérifié sur le code réel plutôt que supposé. Le moteur de conversion a été exécuté sur un échantillon de deux lignes contenant les codes 00123 et 00456, les codes postaux 02138 et 07477, les identifiants à 18 chiffres 123456789012345678 et 987654321098765432, les dates 2026-03-04 et 2026-04-03, les noms accentués Zoë Café et Müller, et les notes fragile; handle with care et gift. Avec des délimiteurs virgules, il a produit chaque valeur à l'identique, avec le nom contenant une virgule entre guillemets et rien d'autre entre guillemets. Avec des délimiteurs points-virgules, il a mis entre guillemets exactement la note contenant un point-virgule et rien d'autre. Donc si votre fichier converti montre des valeurs modifiées après un passage dans Excel, la conversion n'a rien abîmé. Le fichier était correct, et Excel a deviné à l'ouverture et a réécrit ses suppositions à l'enregistrement.

Comma delimited (verified, real converter output):
code,zip,id,shipDate,name,note,price
00123,02138,123456789012345678,2026-03-04,"Zoë, Café",fragile; handle with care,19.99
00456,07477,987654321098765432,2026-04-03,Müller,gift,5

Semicolon delimited (verified, same sample):
code;zip;id;shipDate;name;note;price
00123;02138;123456789012345678;2026-03-04;Zoë, Café;"fragile; handle with care";19.99
00456;07477;987654321098765432;2026-04-03;Müller;gift;5

Codes, ZIPs, long IDs, and dates all survive byte-identically.
Quoting follows the delimiter: only values holding the delimiter
are quoted, in both cases.

Cela vous donne deux options propres pour les fichiers convertis. La première est la voie de la modification sûre : si vous devez modifier un fichier converti, modifiez le JSON et convertissez à nouveau, ce qui produit un fichier frais sans aucun dommage d'aller-retour, au lieu de modifier le CSV dans Excel et de l'enregistrer par dessus. La deuxième est la voie de l'importation : ouvrez le fichier téléchargé avec Données, puis À partir d'un texte/CSV, définissez les colonnes de codes et d'identifiants en Texte et les colonnes de dates en Texte ou en Date avec les paramètres régionaux de la source, effectuez votre travail, et exportez avec Enregistrer sous sous un nouveau nom en CSV UTF-8, en vérifiant le résultat dans un éditeur de texte. Ne collez pas la sortie convertie dans un tableur pour l'enregistrer ensuite par dessus le téléchargement, parce que cet aller-retour peut introduire exactement les écarts de délimiteur, d'encodage et de type que ce guide et ses compagnons existent pour prévenir. Corrigez l'ouverture, ou régénérez depuis la source, jamais le fichier enregistré.

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 tout ce qu'Excel fait ensuite. Un fichier peut porter le bon délimiteur et revenir quand même avec des dates inversées, ou les bonnes dates et le mauvais délimiteur, ou les deux faux à la fois, parce que le délimiteur choisi au moment de la conversion n'est pas le délimiteur qu'Excel écrit au moment de l'enregistrement. Si votre fichier converti s'ouvre dans une seule colonne et que ses valeurs semblent fausses, corrigez les deux dans la même importation : choisissez le délimiteur retenu au moment de la conversion, et définissez explicitement les colonnes sensibles. Le guide compagnon sur le problème de la colonne unique couvre la moitié délimiteur en détail, le guide sur l'encodage couvre la moitié caractères, et le guide sur les zéros initiaux couvre la moitié nombres, et les trois sont liés dans les guides associés ci-dessous.

Liste de prévention : exporter des CSV pour que personne n'ait à les corriger

La devinette de type et les réécritures d'enregistrement sont des écarts entre l'auteur et le lecteur, donc la prévention consiste à faire en sorte que l'auteur déclare ce que sont les valeurs, d'une façon que le lecteur respectera, et à faire en sorte que le lecteur vérifie avant de faire confiance. Parcourez cette liste de contrôle quand vous produisez ou recevez un CSV, et la prochaine personne qui le touchera n'aura pas besoin de ce guide. Premièrement, conservez les données sources. Un CSV est un instantané aplati, pas la donnée elle-même, donc si un enregistrement tourne mal, la source vous permet d'exporter à nouveau proprement au lieu de réparer une copie abîmée. Deuxièmement, n'enregistrez jamais par dessus un original. Gardez un dossier originaux, travaillez sur des copies, et nommez les exports avec une date pour que rien n'écrase rien silencieusement.

Troisièmement, quand vous exportez depuis Excel, choisissez CSV UTF-8, vérifiez le réglage du séparateur de liste avant l'enregistrement, et contrôlez l'export dans un éditeur de texte avant de l'envoyer. Quatrièmement, quand vous recevez un fichier, ouvrez-le d'abord dans un éditeur de texte si quelque chose semble anormal, et confirmez le délimiteur, l'encodage et les colonnes sensibles avant de laisser un tableur l'enregistrer par dessus. Cinquièmement, dites aux destinataires comment ouvrir le fichier : une note d'une ligne indiquant d'importer avec les colonnes de codes définies en Texte et les dates définies en Texte ou en Date avec les paramètres régionaux de la source prévient toute cette catégorie de problèmes, et elle ne coûte rien à joindre au fichier. La plupart des histoires d'horreur de CSV se terminent par quelqu'un qui découvre trop tard que le fichier abîmé était la seule copie. Ne laissez pas ce fichier être le vôtre.

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) →
• Pourquoi Excel supprime les zéros non significatifs de vos codes CSV, et comment les conserver (Guide 2026) →
• Fichier CSV trop volumineux pour Excel : pourquoi Excel ne l'ouvre pas et que faire à la place (Guide 2026) →

Questions fréquentes