Pourquoi Excel change les dates de votre 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 dates changent, c'est de savoir si les données sont abîmées ou simplement mal lues, parce que les deux cas appellent des corrections très différentes, et que la mauvaise correction peut transformer un simple problème d'affichage en véritable perte de données. Voici le test en 30 secondes. Ouvrez le même fichier dans un éditeur de texte brut, le Bloc-notes sous Windows ou TextEdit en mode texte brut sur Mac. Si les dates y apparaissent exactement comme la source les a écrites, 03/04/2026, 2026-03-04, 1-2, vos données sont intactes et seule la lecture par Excel est fausse. Le fichier sur le disque contient les bons caractères, et Excel a changé leur sens quand il a ouvert le fichier. C'est le cas le plus courant, et chaque solution de ce guide part de là.

Le deuxième indice, c'est de repérer quelles valeurs ont changé. Si les mots ordinaires, les nombres courts et la ponctuation semblent corrects, mais que les dates ont bougé, ont été inversées ou ont été reformatées, et que des codes courts comme 1-2 ou MARCH1 sont devenus des dates, vous êtes face à une devinette de type, pas à 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 modifie exactement les valeurs qui ressemblent à des dates, et laisse tout le reste intact. Si 03/04/2026 est devenu le 3 avril sur une machine qui aurait dû lire le 4 mars, et qu'un code comme 1-2 est devenu le 2 janvier, Excel a traité du texte comme des dates, et cela vous indique à la fois la cause et la solution.

La troisième vérification décide si un sauvetage est encore possible, et elle utilise la barre de formule, pas la cellule. Cliquez sur une cellule dont la date a changé et lisez la barre de formule. Si la barre de formule affiche un numéro de série comme 46085, ou une date présentée dans un ordre différent de celui du fichier, la cellule contient désormais une valeur de date Excel, et non vos caractères. Si la barre de formule affiche les caractères d'origine, seul le format d'affichage a changé, et reformater la cellule suffit à corriger le problème. En attendant d'avoir vérifié, gardez le fichier d'origine intact, travaillez sur une copie, et n'enregistrez jamais un fichier converti par-dessus le bon fichier.

Pourquoi Excel devine : un fichier CSV ne contient aucun type de données

Pour comprendre pourquoi cela se reproduit sans cesse, il faut connaître un fait sur le format CSV : un fichier CSV est du texte brut, sans en-tête qui indique quelles valeurs sont des dates, lesquelles sont des nombres et lesquelles sont du texte. 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 ce que chaque valeur signifie, et les programmes ne décident pas tous de la même façon. Le module csv de Python et Google Sheets conservent les valeurs CSV sous forme de texte sauf indication contraire, ce qui explique pourquoi le même fichier y semble correct. Excel, quand vous double-cliquez sur un fichier CSV, devine : tout ce qui ressemble à une date devient une date, tout ce qui ressemble à un nombre devient un nombre, et il ne vérifie pas si cette devinette était juste.

Cette devinette est tout le problème pour les dates, parce que la notation des dates n'est pas universelle. Les États-Unis écrivent le mois d'abord, 03/04/2026 pour le 4 mars. La plupart des pays d'Europe écrivent le jour d'abord, 03/04/2026 pour le 3 avril. La norme ISO 8601 écrit l'année d'abord, 2026-03-04, ce qui ne laisse aucune ambiguïté, mais la plupart des fichiers exportés ne l'utilisent pas. Un fichier CSV ne dit pas quelle convention suivent ses dates, donc Excel se rabat sur la convention de la machine qui l'ouvre. Ouvrez le même fichier à New York et à Berlin et vous obtenez deux tableurs différents à partir d'un seul fichier, sans qu'aucune des deux machines ne vous avertisse qu'un choix a été fait. La même logique explique la deuxième victime : des valeurs qui ne sont pas du tout des dates, comme la plage 1-2, le ratio 5/6 ou le code MARCH1, ressemblent suffisamment à un modèle de date pour qu'Excel les convertisse aussi. 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 "2026-03-04" et la chaîne "03/04/2026" sont deux chaînes différentes, et une conversion de JSON vers CSV écrit chacune exactement telle qu'elle est écrite. 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 dates 2026-03-04, 03/04/2026 et 2026-03-04T10:30:00Z, et il a produit chaque valeur à l'identique dans le CSV, sans reformatage et sans aucun chiffre modifié. Savoir que le décalage se situe à l'étape de l'ouverture, et non à l'étape de la conversion, vous indique où corriger : à l'importation, avant qu'Excel ne devine, comme le montrent les sections suivantes.

Trois façons dont la devinette modifie les dates, et comment les distinguer

La devinette de type modifie les dates de trois façons distinctes, et savoir les distinguer est important parce que seules certaines d'entre elles sont réparables. La première est l'inversion jour mois : 03/04/2026 devient le 3 avril au lieu du 4 mars, ou l'inverse, en silence. Rien ne semble cassé. La colonne est remplie de dates plausibles, toutes valides, et un quart de vos dates sont fausses d'une façon qu'aucun message d'erreur ne signalera jamais. L'inversion ne se produit que lorsque le jour est inférieur ou égal à 12, parce que c'est seulement dans ce cas que le jour peut passer pour un mois. C'est ce qui la rend dangereuse : les lignes qui ne peuvent pas s'inverser trahissent le problème, tandis que les lignes qui se sont inversées le cachent.

La deuxième façon est la colonne mixte, et c'est elle qui révèle qu'une inversion s'est produite. Quand un fichier au format américain est ouvert sur une machine jour d'abord, les lignes dont le jour est supérieur ou égal à 13 ne peuvent pas être des mois, donc Excel laisse ces cellules sous forme de texte tout en convertissant les autres en dates. Une même colonne contient alors deux sortes de cellules : de vraies dates pour les douze premiers jours de chaque mois, et du texte pour le reste. Trier cette colonne place les lignes de texte à une extrémité, filtrer par date les rate, et tout graphique ou calcul construit sur la colonne les ignore silencieusement. Si votre colonne de dates se trie bizarrement, ou si certaines lignes refusent de se comporter comme des dates, vérifiez cette séparation avant d'accuser les données.

La troisième façon est la valeur qui n'est pas une date mais qui est convertie en date : la plage 1-2 devient le 2 janvier, le ratio 5/6 devient le 6 mai, le code MARCH1 devient le 1er mars. En coulisses, Excel enregistre une date sous forme de numéro de série, le nombre de jours écoulés depuis le 30 décembre 1899, donc le 4 mars 2026 est enregistré comme 46085 et le 3 avril 2026 comme 46115. Une fois qu'une valeur est devenue un numéro de série, les caractères d'origine ont disparu de ce classeur. Formater ensuite la cellule en Texte ne les ramène pas : cela affiche 46085, le numéro de série rendu sous forme de texte, et non 2026-03-04. C'est le test qui sépare un problème d'affichage d'une perte de données. Si la barre de formule affiche le numéro de série, les caractères ont disparu de cette copie, et seule la section de sauvetage peut aider.

CSV file (from this page converter, verified):
order,shipDate,dueDate,window,code
A-101,2026-03-04,03/04/2026,1-2,MARCH1
A-102,2026-04-03,04/03/2026,12-3,SEPT2
A-103,2026-03-04T10:30:00Z,3/4/2026,5/6,OCT4

What Excel shows on double-click, US machine (month first):
shipDate -> real dates, displayed 3/4/2026, 4/3/2026, 3/4/2026
window -> 1-2 becomes Jan-02, 12-3 stays text, 5/6 becomes Jun-05
code -> MARCH1 becomes Mar-01, SEPT2 becomes Sep-02, OCT4 becomes Oct-04

What Excel shows on double-click, day-first machine:
dueDate 03/04/2026 -> April 3 (was March 4); 04/03/2026 -> March 4 (was April 3)
dueDate 3/4/2026 -> April 3 (was March 4); rows with day above 12 stay text

Remarquez ce que ce tableau prouve : rien ne manque dans le fichier, et tout est modifié dans l'affichage Excel. C'est pourquoi la correction par l'importation fonctionne si complètement. Quand vous indiquez à Excel qu'une colonne est de type Texte avant le chargement, il enregistre les mêmes caractères sans aucune conversion, et chaque date retrouve son sens, sans retouche et sans ressaisie. Si votre fichier correspond à ce modèle, sautez la section qui démonte les idées reçues et passez directement à la correction par l'importation. Vous n'avez pas un fichier abîmé. Vous avez un fichier mal lu.

Quatre fausses solutions, et pourquoi on continue de les essayer

Avant les solutions qui fonctionnent, il vaut la peine d'écarter les quatre fausses solutions, parce que chacune fait perdre du temps et que l'une d'entre elles aggrave les choses. La première consiste à reformater la colonne après avoir ouvert le fichier. Changer le format de nombre modifie la façon dont une date enregistrée s'affiche, mais ne peut pas changer quelle date a été enregistrée. Si Excel a enregistré le 3 avril alors que le fichier voulait dire le 4 mars, le reformatage affiche le 3 avril dans un autre style, et la mauvaise date reste fausse. La mise en forme, c'est l'affichage. Le numéro de série enregistré, c'est la donnée, et les changements d'affichage ne la touchent jamais.

La deuxième consiste à modifier les paramètres régionaux de votre système après l'importation. Ces paramètres comptent au moment où Excel lit le fichier, pas après. Une fois les numéros de série enregistrés, passer la machine du mois d'abord au jour d'abord ne fait que modifier l'affichage des numéros de série enregistrés, exactement comme un reformatage. Cela ne relit pas le fichier, et cela n'annule aucune inversion. La troisième consiste à mettre les valeurs entre guillemets dans le CSV. Beaucoup de guides affirment qu'écrire "03/04/2026" entre guillemets protège la date. Ce n'est pas le cas, dans Excel. Excel supprime les guillemets pendant l'importation puis applique la même devinette de date à la valeur qu'ils contenaient, donc la date entre guillemets se convertit exactement comme la date 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.

La quatrième consiste à utiliser rechercher-remplacer sur les dates converties, en réinversant mois et jour à la main ou par formule sur toute la colonne. Cela ne fonctionne que si chaque ligne s'est inversée, ce qui n'arrive jamais : les lignes dont le jour est supérieur à 12 ne se sont jamais inversées, elles sont restées sous forme de texte, donc une inversion globale corrompt les lignes qui étaient justes tout en corrigeant celles qui étaient fausses. Réservez rechercher-remplacer aux valeurs que vous avez saisies à la main, et utilisez la correction par l'importation pour les fichiers. Savoir quelles solutions échouent vous évite 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 enregistrées sont toujours fausses.

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

C'est la solution à essayer en premier, parce qu'elle ne change rien à votre système, rien au fichier, et qu'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'importation guidée, où vous choisissez vous-même le type de chaque colonne. L'aperçu dans la boîte de dialogue d'importation vous montre immédiatement si vous avez bien choisi : les dates s'y affichent exactement comme elles sont écrites dans l'aperçu, avec les mêmes caractères que dans le fichier, avant tout chargement. Si l'aperçu montre encore des dates converties, 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 Data, puis From Text/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 Transform Data au lieu de Load, pour ouvrir l'éditeur Power Query.
• ▸Dans l'éditeur Power Query, trouvez l'étape automatique Changed Type et supprimez-la, parce que c'est à cette étape que la devinette de date se produit.
• ▸Sélectionnez chaque colonne de dates, ainsi que chaque colonne de codes qui ressemble à une date, et définissez le type de données sur Texte.
• ▸Cliquez sur Close and Load. Les dates arrivent sous forme de texte, avec chaque caractère exactement tel qu'il est écrit.

Les dates en texte ont un inconvénient honnête à comprendre. Une date en texte n'est pas une vraie date Excel : elle ne se triera pas chronologiquement avec de vraies dates, et les formules de dates l'ignoreront jusqu'à ce que vous la convertissiez délibérément. C'est une qualité, pas un défaut, quand l'objectif est de préserver les caractères de la source. Convertissez ensuite délibérément, avec la solution suivante, une fois que vous connaissez la convention de la source. Faites de l'importation votre façon par défaut d'ouvrir les fichiers CSV, et pas seulement votre solution de secours. Double-cliquer, c'est deviner le délimiteur, l'encodage et le type de chaque colonne. Importer, c'est choisir les trois, et ce choix prend environ une minute de plus. Sur Mac, le même chemin fonctionne via Data, puis From Text, avec les types de colonnes définis à l'étape d'importation.

Solution 2 : importez avec la langue du fichier source, pour que la conversion soit celle que vous vouliez

Si vous avez besoin de vraies dates Excel, et non de texte, la voie de l'importation fonctionne toujours, avec une étape supplémentaire : indiquez à Excel quelle convention le fichier source utilise. Dans l'éditeur Power Query, faites un clic droit sur la colonne de dates, choisissez Change Type, puis Using Locale. Choisissez Date comme type de données et la langue qui correspond au fichier source, English (United States) pour les fichiers mois d'abord, ou la langue jour d'abord qui correspond à un export européen. Power Query convertit alors chaque ligne selon cette seule convention, y compris les lignes dont le jour est supérieur à 12, donc la colonne ressort uniforme : que des vraies dates, aucune ligne de texte restante, aucune inversion silencieuse.

Vérifiez le résultat avant le chargement, en utilisant les lignes qui trahissent une inversion. Trouvez des enregistrements dont le jour est supérieur à 12 : avec la bonne langue, ils se chargent comme des dates, avec la mauvaise, ils restent en texte ou échouent. Trouvez ensuite un enregistrement dont le jour et le mois sont tous deux inférieurs ou égaux à 12 et vérifiez qu'il se lit comme la source le voulait. Si l'une des deux vérifications échoue, vous avez choisi la mauvaise langue, et vous n'avez rien perdu, parce que rien n'est encore chargé. Changez de langue et vérifiez à nouveau. Cette vérification en deux enregistrements prend dix secondes et repère l'erreur qui, sinon, resterait cachée pendant des mois.

Solution 3 : réparez des dates déjà importées, sans réimporter

Parfois, réimporter n'est pas possible, parce que le fichier d'origine a disparu et que seul le classeur survit. Ce que vous pouvez réparer dépend de ce qui a survécu. Si les dates importées sont encore en texte, parce qu'Excel ne les a pas reconnues, l'outil Text to Columns les répare : sélectionnez la colonne, allez dans Data, puis Text to Columns, cliquez deux fois sur Next, et à l'étape 3 choisissez Date et le format qui correspond au fichier d'origine, MDY pour le mois d'abord ou DMY pour le jour d'abord. Excel convertit alors toute la colonne selon cette seule convention, ce qui est exactement le contrôle que le double-clic ne vous a jamais donné.

Si les dates ont été enregistrées sous forme de mauvais numéros de série, parce que chaque ligne s'est inversée, une formule peut les réinverser : dans une colonne d'aide, =DATE(YEAR(A2),DAY(A2),MONTH(A2)) reconstruit chaque date en échangeant le jour et le mois, et copier les résultats puis les coller en valeurs fige la réparation. Mais cela ne fonctionne que si chaque ligne de la colonne s'est inversée, ce qui signifie que chaque jour d'origine était inférieur ou égal à 12. Si la colonne est mixte, des dates plus des lignes de texte restantes, réparez les deux groupes séparément : convertissez d'abord les lignes de texte avec Text to Columns, puis vérifiez si les lignes de dates ont vraiment besoin d'être inversées. Une formule globale sur une colonne mixte corrompt les lignes qui étaient justes. Et si les caractères d'origine ont disparu et que vous ne pouvez pas dire quelles lignes se sont inversées, arrêtez-vous : aucune formule ne peut récupérer une information que le fichier ne contient plus, et la section de sauvetage est votre seule voie honnête.

Solution 4 : désactivez la conversion automatique des dates, et écrivez des dates ISO à la source

Si vous ouvrez des fichiers CSV tous les jours, importer chaque fois devient lassant, 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 des données, sous File, puis Options, puis Data. Il liste les conversions qu'Excel applique de lui-même, y compris la conversion des chaînes de lettres et de chiffres qui ressemblent à des dates. Décochez les conversions que vous ne voulez pas, et Excel laissera ces valeurs en texte lors des ouvertures suivantes, 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 caractères déjà remplacés par des numéros de série. Un fichier que vous avez ouvert la semaine dernière contient toujours les valeurs converties dans le classeur, et seule une nouvelle importation depuis le fichier d'origine ramènera les dates. Ensuite, ce paramètre vit sur votre machine, pas dans le fichier. Un collègue qui ouvre le même fichier sur une machine avec le paramètre par défaut verra toujours des dates converties, et un fichier que vous envoyez ne transporte aucune protection avec lui. Considérez ce paramètre comme un confort pour votre propre machine, et la correction par l'importation comme la méthode fiable pour les fichiers que vous partagez.

Si vous produisez le CSV, la solution la plus solide se situe à la source : écrivez les dates au format ISO 8601, année d'abord, 2026-03-04. Les dates année d'abord ne laissent aucune ambiguïté jour mois à résoudre pour aucun lecteur, parce que l'année vient en premier et que le mois est toujours le nombre du milieu. Cela ne rend pas Excel infaillible, donc vérifiez quand même l'importation, mais cela supprime toute la catégorie d'erreurs d'inversion que les dates avec barres obliques et tirets invitent. En JSON, cela signifie conserver les dates sous forme de chaînes au format ISO, et non de chaînes formatées selon une langue : la chaîne "2026-03-04" se convertit en caractères 2026-03-04, tandis qu'une chaîne de langue comme "03/04/2026" transporte son ambiguïté dans chaque fichier qu'elle touche. C'est une décision sur les données source, pas un paramètre de convertisseur, parce qu'aucun convertisseur ne peut déclarer une convention que la source n'a jamais énoncée.

Récupérez un fichier déjà enregistré avec des dates converties

Jusqu'ici, chaque solution a supposé que le fichier sur le disque est toujours correct et que seul l'affichage Excel est faux. Mais parfois, la version convertie a déjà été enregistrée, et la question devient de savoir si les dates d'origine peuvent encore être récupérées à partir de la copie enregistrée. La réponse dépend exactement de ce que l'enregistrement a fait, et il y a deux cas à distinguer. Dans le premier cas, le fichier sur le disque contient toujours les caractères d'origine, 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 dates d'origine, donc rien n'est perdu, et la solution 1 répare l'affichage. Dans le deuxième cas, le fichier sur le disque contient désormais les valeurs converties elles-mêmes, parce que quelqu'un l'a ouvert dans Excel, a vu les dates reformatées, 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 date s'est inversée selon une seule convention et que chaque jour d'origine était inférieur ou égal à 12, la formule DATE de la solution 3 les réinverse, parce que le dommage est un échange uniforme. Travaillez sur une copie, jamais sur la seule version, et vérifiez le résultat par rapport à un enregistrement connu avant de l'ouvrir à nouveau dans Excel. Si le dommage est mixte, certaines lignes inversées, certaines lignes 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 numéro de série n'enregistre pas quelle convention l'a produit. 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 de vérifier le remplaçant, c'est transformer un problème récupérable en ensemble 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 genre de fichier dont parle ce guide, il vaut donc la peine d'énoncer son comportement clairement. Le téléchargement préserve les dates exactement telles que 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 la date ISO 2026-03-04, les dates avec barres obliques 03/04/2026 et 04/03/2026, l'horodatage 2026-03-04T10:30:00Z, et les codes ressemblant à des dates 1-2, 12-3, 5/6, MARCH1, SEPT2 et OCT4, et il a produit chaque valeur à l'identique dans le CSV, sans reformatage, sans conversion et sans aucun chiffre modifié. Donc, si votre fichier converti affiche des dates modifiées dans Excel, la conversion n'a rien abîmé. Le fichier est correct, et Excel a deviné les types au double-clic.

Cela vous donne deux options nettes pour les fichiers convertis. La première est la voie de l'importation : ouvrez le fichier téléchargé avec Data, puis From Text/CSV, cliquez sur Transform Data, définissez chaque colonne de dates sur Texte pour conserver les caractères, ou sur Date avec la langue du fichier source si vous avez besoin de vraies dates, puis chargez. Les dates se liront correctement, et vous n'avez rien changé au fichier, donc il reste valide pour tous les autres outils. La deuxième est le paramètre de conversion automatique de la solution 4, 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 ensuite, parce que 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 dates inversées en même temps, ou les bonnes dates et le mauvais délimiteur, ou les deux faux à la fois. Si votre fichier converti s'ouvre dans une seule colonne et que les dates semblent fausses, corrigez les deux paramètres dans la même importation : choisissez le délimiteur que vous aviez choisi au moment de la conversion, et définissez les colonnes de dates sur Texte ou sur Date avec la langue du fichier source. Le guide compagnon sur le problème d'une seule colonne couvre en détail la moitié délimiteur, le guide sur l'encodage couvre la moitié caractères, et le guide sur les zéros non significatifs couvre la moitié nombres, et les trois sont liés dans les guides associés ci-dessous.

Checklist de prévention : exportez vos dates 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 les valeurs sont, d'une façon que le lecteur respectera. Passez en revue cette checklist quand vous produisez un CSV, et la prochaine personne qui l'ouvrira n'aura pas besoin de ce guide. D'abord, écrivez les dates au format ISO 8601, année d'abord, à la source. Si vos données contiennent des dates, stockez-les sous forme de chaînes ISO dans le système source, parce qu'une date formatée selon une langue transporte son ambiguïté dans chaque 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 dates définies sur Texte, ou sur Date avec la langue du fichier source, prévient tout le problème, et cela ne coûte rien de la joindre au fichier.

Troisièmement, n'enregistrez jamais un fichier récupéré par-dessus l'original tant que vous n'avez pas vérifié la récupération 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 dates avant de laisser un tableur l'écraser. Et cinquièmement, gardez les données source. Un CSV est un instantané aplati, pas les données elles-mêmes, donc si une récupération tourne mal, la source vous permet de réexporter proprement au lieu de réparer une copie abîmée. La plupart des histoires d'horreur sur les dates se terminent par quelqu'un qui découvre trop tard que le CSV 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) →
• 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