Les totaux collaient. Les codes n’avaient plus leurs zéros.

L’export s’ouvre dans le tableur : les colonnes s’alignent et les totaux collent avec l’écran métier. Rien ne signale une erreur. Le fichier part ensuite vers l’outil suivant — import partenaire, reprise comptable, alimentation d’un autre logiciel. Chez le destinataire, des codes n’ont plus leurs zéros de tête, une colonne a glissé, ou une date a été lue au format américain. Dans ce scénario illustratif, fréquent en reprise d’existant, le fichier « avait l’air juste » à l’écran ; la clé métier n’était plus la même après ouverture ou import.

Le problème n’est pas un CSV « mal écrit » au sens d’un bug d’export unique. C’est la confusion entre trois objets distincts : le fichier texte généré par l’application, la vue interprétée par le tableur, et le schéma attendu par le consommateur. Chacun applique ses défauts. Tant qu’on valide seulement ce qui s’affiche et ce qui s’additionne, on rate les transformations qui touchent les identifiants, les séparateurs et les dates — celles qui cassent la jointure sans faire rougir un total.

Symptôme : totaux OK, clés métier altérées

Sur l’écran source, le code article 00142 est stable. Après ouverture dans un tableur, la cellule affiche 142. Les montants restent cohérents : on additionne des nombres, pas des clés textuelles. L’import aval peut répondre « succès » sur une partie des lignes. Plus tard, une commande ne trouve plus son article, un doublon apparaît, ou le partenaire renvoie le lot. Le ticket arrive souvent sous l’étiquette « problème d’Excel » ou « mauvais séparateur » — formulations qui mélangent déjà plusieurs causes.

Dans une classe fréquente de flux en reprise back-end, on observe aussi : téléphone sans préfixe, grand identifiant en notation scientifique, accents cassés selon la machine, date 03/04/2026 lue comme 3 avril ou 4 mars selon le local, adresse contenant le séparateur et décalant les colonnes suivantes. L’import « réussi à moitié » reste le plus coûteux : pas d’alerte rouge globale, lignes acceptées avec une valeur tronquée, découverte métier des semaines plus tard.

Cause : trois objets, trois langages

Le fichier généré est du texte : octets, encodage, séparateur, guillemets, fins de ligne. Le tableur n’affiche pas ce texte tel quel : il convertit. Il décide qu’une colonne « a l’air » numérique ou date, retire les zéros de tête, réécrit une date selon le local, parfois propose une resauvegarde qui fige ces conversions. Le schéma d’import applique encore d’autres règles : types, longueurs, format de date unique, rejet ou troncature. Chaque étage a appliqué son défaut sans que le contrat d’échange soit écrit.

Confondre les trois étages produit des correctifs inutiles. On change de librairie CSV alors que le brut était correct et que c’est l’ouverture tableur qui a mangé les zéros. On « force UTF-8 partout » alors que l’écart est un séparateur point-virgule lu comme virgule. On demande au métier de « faire attention » à ne pas resauvegarder, alors que la resauvegarde manuelle est devenue une étape officielle. Nommer l’étage fautif — génération, interprétation tableur, ou validation consommateur — change le correctif.

Une recette CSV/Excel n’est pas une garantie universelle. Forcer le texte ou ajouter un BOM aide souvent quand le fichier sera ouvert sous tableur, mais ne remplace pas un schéma d’import strict ni un format de date non ambigu (idéalement ISO). Inversement, un import impeccable ne répare pas un export qui omet les guillemets autour d’un champ contenant le séparateur. Format fichier, interprétation tableur et contrat consommateur se testent séparément.

Tests discriminants : hypothèse, geste, résultat

Avant de réécrire l’export entier, on sépare les causes avec des gestes courts sur un scénario illustratif — fixture avec zéros de tête, accents, date limite, ligne volontairement cassée.

Hypothèse 1 — conversion tableur, pas défaut de génération. Test : ouvrir le même fichier dans Excel (ou équivalent) et le lire en brut (éditeur texte, ou lecture octet à octet pour BOM et séparateur). Comparer une clé métier (SKU, code client, téléphone) avant ouverture et après affichage. Résultat attendu si l’hypothèse tient : le brut conserve 00142 et les guillemets ; le tableur affiche 142 ou une date réécrite. Conclusion : corriger l’interprétation (forcer texte à l’export, ou interdire la resauvegarde comme étape officielle), pas seulement « changer de parser ».

Hypothèse 2 — séparateur, encodage ou guillemets au mauvais étage. Test : compter les colonnes sur la première ligne et sur une ligne contenant le séparateur dans un libellé ; vérifier l’encodage annoncé vs celui détecté ; rouvrir sur une autre machine ou un autre local. Résultat attendu si l’hypothèse tient : décalage dès la ligne « sale », ou accents cassés selon l’outil. Conclusion : fixer séparateur, encodage et quoting dans le contrat d’échange, et rejeter si le nombre de colonnes dérive.

Hypothèse 3 — schéma d’import permissif. Test : importer une fixture connue — zéros exigés, accent, date ambiguë, mauvais nombre de colonnes — et lire le rapport ligne à ligne. Résultat attendu si l’hypothèse tient : succès partiel, troncature silencieuse, ou date stockée différente de la date métier. Conclusion : valider le schéma avant l’écriture en base ; une ligne hors contrat doit échouer avec un motif lisible, pas « ce qu’on peut ».

Ces trois tests tiennent souvent en une demi-journée. Ils collent à des artefacts — brut vs ouvert, clé avant/après, rapport d’import — plutôt qu’à un débat d’intention (« chez nous ça marchait »).

généré  → texte (séparateur, encoding, quoting, BOM?)
ouvert  → vue tableur (types inférés, dates locales, resauvegarde)
importé → schéma (types, longueurs, date ISO?, rejet explicite)
fixture → zéros | accents | date limite | ligne cassée

Correction maintenant, prévention ensuite

La correction traite ce qui bloque aujourd’hui. À l’export, les colonnes sensibles (codes, références, identifiants, téléphones) partent explicitement en texte : guillemets systématiques, et si le fichier sera ouvert sous tableur, les précautions utiles dans ce contexte (BOM UTF-8 quand c’est pertinent, préfixe qui empêche la conversion numérique sur les cellules critiques). On n’exporte pas « ce qui s’affiche bien sur la machine du développeur ». Côté import, on valide le schéma avant d’écrire : nombre de colonnes, types, longueur des clés, zéros exigés par le métier, un seul format de date. Une ligne hors contrat est rejetée avec un motif lisible par le métier.

La prévention se pose une fois le flux diagnostiqué. On écrit le contrat d’échange : colonnes en texte forcé, séparateur, encodage, format de date, colonnes obligatoires, règle si une ligne est invalide. On distingue un export « lecture humaine » d’un export « machine » si les deux usages coexistent — et on ne laisse pas la resauvegarde manuelle devenir une étape officielle. Les fixtures de non-régression reprennent zéros, accents, dates limites et une ligne cassée. On ne se repose pas sur un total qui colle : on compare des clés métier avant génération, après lecture brute, après ouverture tableur, et après import.

Séparer correction et prévention évite un piège classique : croire qu’un préfixe texte dans Excel suffit pour toujours. Ce geste peut stabiliser une ouverture manuelle ; il ne remplace pas un schéma consommateur strict, ni un accord écrit sur le séparateur et la date. Inversement, un contrat papier sans test d’ouverture tableur en recette rejoue la même ambiguïté à chaque envoi.

Limites

Ce texte décrit une classe fréquente de dérives export CSV / tableur / import, pas un ticket nominatif. Les vecteurs listés (zéros de tête, séparateur, encodage, dates ambiguës, guillemets) ne sont pas exhaustifs : fins de ligne mélangées, champ multiligne mal quoté, ou fuseau mal documenté peuvent jouer le même rôle. Le bon réflexe reste hypothèse, test sur artefact, conclusion — plutôt qu’une checklist à recopier sans lire le flux.

Si le métier exige qu’un humain ouvre et « vérifie » le fichier dans un tableur avant envoi, ce geste fait partie du contrat et doit être conçu comme tel (export lecture distinct, colonnes texte forcées, interdiction de resauvegarder par-dessus le fichier machine). Si ce geste reste informel, chaque ouverture rejoue les conversions. Quand l’import partenaire a ses propres défauts hors de votre contrôle, documentez ce que vous garantissez à la génération et ce que vous refusez à la réception — sans promettre qu’« Excel ne convertira jamais ».

Si vos exports ont l’air justes à l’écran et divergent chez le partenaire ou à la reprise, le cadre de lecture (génération, ouverture, schéma) est décrit côté expertise Scott-E.