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

Le CSV s’ouvre dans le tableur. Les colonnes s’alignent. Les totaux collent avec l’écran métier. Rien ne crie l’erreur. Le fichier part vers l’outil suivant — import partenaire, reprise comptable, alimentation d’un autre logiciel. Là, le contrat casse. Des codes produits sans leurs zéros de tête. Une colonne qui a glissé d’un cran. Des dates lues au format américain. Un séparateur qui n’est plus le même. Chez nous, le fichier « avait l’air juste ». En aval, il ne l’était plus.

Ce n’est pas le même incident que deux jobs qui écrivent en même temps. Ici, un seul export, un seul fichier, et pourtant le métier se dégrade dès qu’un humain ou un import automatisé ouvre le tableur. En maintenance comme en back-end, on croise ce motif dès qu’un CSV sert de pont entre deux systèmes. Le risque n’est pas cosmétique. C’est de la donnée fausse acceptée parce qu’elle ressemble à de la donnée vraie.

Le fichier « a l’air juste » — ce qui casse en aval

Le piège commence à l’ouverture. Le tableur convertit. Il interprète. Il « aide ». Un code article 00142 devient 142. Un identifiant client avec un zéro initial disparaît. Une colonne de téléphones perd le préfixe. Sur l’écran, les chiffres restent lisibles. Les sommes peuvent même coller si on additionne des montants. Le contrat métier, lui, repose souvent sur des clés textuelles stables. Sans le zéro, la jointure échoue, le doublon se crée, ou l’import mappe la mauvaise fiche.

Les symptômes qu’on retrouve se ressemblent d’un projet à l’autre :

• Codes, références, SKU ou identifiants numériques « trop propres » : zéros de tête mangés, parfois une notation scientifique sur les grands numéros.
• Séparateur point-virgule en France, virgule ailleurs : une colonne fusionne, la suivante se décale, l’import lit encore « succès » sur les premières lignes.
• Encodage : accents cassés, caractères spéciaux transformés, parfois un fichier lu moitié UTF-8, moitié Windows-1252 selon la machine qui l’ouvre.
• Dates ambiguës : 03/04/2026 lu comme 3 avril ou 4 mars selon le local. Le tableur affiche une date. L’outil suivant en stocke une autre.
• Guillemets absents autour d’un champ qui contient le séparateur : une adresse, un libellé, un commentaire. La ligne éclate. Les colonnes glissent. Les lignes suivantes héritent du décalage.

L’import « qui réussit à moitié » est le plus dangereux. Pas d’alerte rouge. Un rapport vert sur 80 % des lignes. Les 20 % restants sont rejetés, ou pire, acceptés avec une valeur tronquée. L’équipe métier découvre le trou plus tard, quand une commande ne trouve plus son article, ou quand un partenaire renvoie le lot.

Le tableur n’est pas le contrat métier

On confond souvent trois objets. Le fichier généré par l’application. La vue dans Excel ou un équivalent. Le schéma attendu par le système qui consomme. Ces trois objets ne parlent pas le même langage. L’export a produit du texte. Le tableur a décidé que certaines colonnes étaient des nombres ou des dates. L’import a appliqué ses propres règles. Personne n’a menti. Chacun a appliqué son défaut.

En reprise d’un existant, on ne commence pas par « changer de librairie CSV ». On commence par nommer le contrat : quelles colonnes sont du texte forcé, quel séparateur, quel encodage, quel format de date, quelles colonnes obligatoires, quelle règle si une ligne est invalide. Tant que ce contrat vit uniquement dans la tête de quelqu’un, chaque ouverture manuelle et chaque nouvel import rejouent le même tirage au sort.

Le CSV qui « passe » en interne et échoue chez le partenaire n’est pas un mystère d’intégration. C’est souvent un fichier ouvert, resauvegardé, renvoyé. La resauvegarde fixe les conversions du tableur. Les zéros ne reviennent pas. Voir aussi la fiabilité des tâches asynchrones : ici le pont est le tableur lui-même.

Un export n’est pas un dump pratique. C’est un document d’échange. S’il doit être relu par un humain, il doit rester fidèle après ouverture. S’il doit être importé, il doit échouer clairement quand une ligne viole le schéma.

Une seule preuve utile : forcer le texte et valider avant d’écrire

À l’export, les colonnes sensibles (codes, références, identifiants, téléphones) partent explicitement en texte : guillemets, et si le fichier sera ouvert sous tableur, un BOM UTF-8 et, pour les cellules critiques, le préfixe qui empêche la conversion numérique. On n’exporte pas « ce qui s’affiche bien chez le développeur ».

Côté import, on valide le schéma avant d’écrire en base. Nombre de colonnes, types, longueur des clés, zéros exigés par le métier, format de date unique (idéalement ISO). Une ligne hors contrat est rejetée avec un motif lisible. On refuse le mode « on importe ce qu’on peut ».

Ce qu’on refuse de laisser en l’état

• Colonnes clés forcées en texte ; test d’ouverture tableur en recette, pas seulement un diff brut.
• Séparateur, encodage et format de date dans le contrat d’échange ; un seul format de date à l’import.
• Guillemets autour des champs qui peuvent contenir le séparateur ; rejet si le nombre de colonnes dérive.
• Validation de schéma avant écriture ; rapport d’erreurs lisible par le métier.
• Pas de resauvegarde manuelle comme étape officielle ; export lecture distinct de l’export machine si un humain doit relire.
• Fixtures : zéros de tête, accents, dates limites, une ligne cassée pour vérifier le rejet.

Si vos exports ont l’air justes et cassent chez le partenaire ou à la reprise, on peut lire le flux : génération, ouverture, import, schéma. Disponibilité mission dès septembre 2026 — expertise, back-end ou maintenance.