Convertir des données entre formats sans perdre la tête
Un guide pratique pour migrer des données entre CSV, JSON, YAML et XML — le vrai pipeline pour les migrations et intégrations.
On connaît la situation. L'export de base de données donne du CSV. La nouvelle API veut du JSON. La config de déploiement a besoin de YAML. Le système legacy ne parle que XML. Et quelque part en cours de route, c'est devenu notre job de faire communiquer tout ça.
La conversion de format de données semble simple jusqu'à ce qu'on le fasse vraiment. Voici comment construire un vrai pipeline qui ne s'effondre pas.
Le scénario : une vraie migration
Imaginons qu'on migre des données utilisateur d'un ancien système vers un nouveau. Voici la situation :
- Source : export CSV de l'ancienne base (10 000 lignes, 15 colonnes)
- Couche API : le nouveau système accepte du JSON via REST API
- Fichiers de config : paramètres de déploiement en YAML
- Intégration legacy : un système partenaire qui exige toujours des flux XML
Quatre formats. Un jeu de données. C'est parti.
Étape 1 : CSV vers JSON — De l'export à l'API
Le CSV ressemble à ça :
id,name,email,plan,created
1,Alice,alice@example.com,pro,2024-03-15
2,Bob,bob@example.com,free,2024-06-22
Converti en JSON, on obtient des données structurées que l'API peut consommer :
[
{
"id": 1,
"name": "Alice",
"email": "alice@example.com",
"plan": "pro",
"created": "2024-03-15"
}
]
Attention aux : champs avec des virgules entre guillemets, valeurs vides qui devraient être null et non des chaînes vides, formats de date qui varient d'une ligne à l'autre. Ces bugs apparaissent à la ligne 4 738 quand on pensait que tout marchait.
Étape 2 : JSON vers YAML — Pour les fichiers de config
Le déploiement a besoin d'une config YAML. La structure des données est la même — juste une syntaxe différente :
users:
- id: 1
name: Alice
email: alice@example.com
plan: pro
created: "2024-03-15"
Le YAML est plus lisible pour les fichiers de config — c'est pourquoi Kubernetes, Docker Compose et les pipelines CI/CD l'utilisent. Mais il est sensible aux espaces : un mauvais retrait et le déploiement crashe à 2h du matin.
Étape 3 : JSON vers XML — Pour les systèmes legacy
Ce système partenaire de 2015 a besoin de XML. Non, ils ne mettront pas à jour leur API. Oui, il faut quand même le supporter.
<users>
<user>
<id>1</id>
<name>Alice</name>
<email>alice@example.com</email>
</user>
</users>
La conversion est directe, mais XML a ses particularités — attributs vs éléments, exigences de namespaces, validation de schéma. Le convertisseur XML gère la transformation structurelle ; la logique métier, c'est votre affaire.
Étape 4 : Tout valider avec le formateur JSON
À chaque étape, formater et valider le JSON. Un crochet mal placé, une virgule en trop, un guillemet non échappé — et l'import perd silencieusement des enregistrements ou crashe complètement.
Avant d'envoyer des données converties à une API, les formater et scanner visuellement la structure. Cinq secondes de formatage économisent cinq heures de débogage sur "pourquoi il manque 200 enregistrements."
Pièges courants en migration de données
Problèmes d'encodage : un CSV d'Excel sur Windows pourrait être en Windows-1252, pas en UTF-8. Les noms de clients avec des accents se transforment en points d'interrogation. Toujours vérifier l'encodage en premier.
Coercition de type : CSV traite tout comme des chaînes. 001 en CSV devient 1 en JSON. Les codes postaux, numéros de téléphone et champs d'ID avec des zéros en tête sont les victimes habituelles.
Données imbriquées : CSV est plat. JSON est imbriqué. Il faut décider comment address_street, address_city, address_zip en CSV se mappe à un objet address en JSON.
Null vs vide : une cellule CSV vide est-elle null, "", ou la clé doit-elle être omise ? À définir avant de commencer, pas quand on découvre le bug.
Le pattern du pipeline
Pour toute migration de données, le workflow est :
- Export — depuis le système source (généralement CSV ou dump SQL)
- Conversion — vers le format de travail (CSV vers JSON)
- Transformation — modifier la structure (renommer les champs, imbriquer les objets, corriger les types)
- Validation — vérifier la sortie (formater et inspecter)
- Conversion — vers le format cible (YAML ou XML)
- Import — dans le système de destination
Les outils gèrent les étapes 2, 4 et 5. Les étapes 1, 3 et 6, c'est votre code. Séparer "conversion" et "transformation" rend tout gérable.
Les migrations de données ne sont jamais aussi simples qu'elles le paraissent dans le document de planification. Mais avec des outils de conversion fiables à chaque étape, on passe son temps sur les vrais problèmes — logique métier, cas limites et qualité des données — au lieu de se battre avec la syntaxe des formats.