Arrêtez d'écrire des instructions INSERT à la main : utilisez un convertisseur JSON vers SQL

Vous avez exporté 200 lignes de données utilisateur depuis un service tiers. Le format est JSON. Votre base de données a besoin d'instructions SQL INSERT. Et pour une raison quelconque, vous envisagez de les écrire à la main.

Ce raisonnement va à peu près ainsi : ouvrir le fichier JSON, regarder la structure, écrire l'instruction CREATE TABLE, puis commencer sur les instructions INSERT. La première prend deux minutes. La deuxième prend une minute. À la dixième, vous avez une routine. À la cinquantième, vous avez introduit une faute de frappe que vous ne remarquerez pas avant l'échec de l'import avec une erreur de contrainte.

Il y a un meilleur moyen. Le convertisseur JSON vers SQL prend votre tableau JSON, déduit le schéma et produit du SQL prêt à l'emploi — des instructions INSERT en masse, avec les bons noms de colonnes et les valeurs correctement citées. Ce guide explique ce que l'outil fait, comment l'utiliser efficacement et où vous devrez encore faire du nettoyage manuel.

Ce que l'outil fait concrètement

En résumé : vous collez un tableau JSON d'objets, sélectionnez un dialecte SQL, et l'outil génère deux choses — une instruction CREATE TABLE basée sur le schéma déduit, et une série d'instructions INSERT pour vos données.

La déduction de type est la partie intéressante. L'outil regarde les valeurs de votre JSON et fait des suppositions raisonnables sur les types SQL. Les chaînes deviennent VARCHAR ou TEXT. Les nombres deviennent INT ou FLOAT. Les booléens deviennent BOOLEAN ou TINYINT(1) selon votre dialecte. Les valeurs null prennent VARCHAR nullable par défaut.

Il gère également automatiquement les différences de formatage entre les dialectes SQL — noms de colonnes entre guillemets inversés pour MySQL, identificateurs entre guillemets doubles pour PostgreSQL, NVARCHAR pour les colonnes texte de SQL Server.

Un exemple réaliste

Disons que vous avez un export JSON d'une application SaaS. L'export de la table users ressemble à ceci :

[
  {
    "id": 1,
    "name": "Alice Chen",
    "email": "alice@example.com",
    "age": 31,
    "active": true,
    "created_at": "2025-01-15T09:23:00Z"
  },
  {
    "id": 2,
    "name": "Ben Kowalski",
    "email": "ben@example.com",
    "age": 28,
    "active": false,
    "created_at": "2025-02-03T14:55:00Z"
  },
  {
    "id": 3,
    "name": "Sara Okonkwo",
    "email": "sara@example.com",
    "age": 34,
    "active": true,
    "created_at": "2025-03-11T08:00:00Z"
  }
]

Collez ça, sélectionnez MySQL, et la sortie ressemble à :

CREATE TABLE `users` (
  `id` INT,
  `name` VARCHAR(255),
  `email` VARCHAR(255),
  `age` INT,
  `active` BOOLEAN,
  `created_at` VARCHAR(255)
);

INSERT INTO `users` (`id`, `name`, `email`, `age`, `active`, `created_at`) VALUES
(1, 'Alice Chen', 'alice@example.com', 31, TRUE, '2025-01-15T09:23:00Z'),
(2, 'Ben Kowalski', 'ben@example.com', 28, FALSE, '2025-02-03T14:55:00Z'),
(3, 'Sara Okonkwo', 'sara@example.com', 34, TRUE, '2025-03-11T08:00:00Z');

Pour 200 lignes, vous obtiendriez la même structure avec un lot de 200 valeurs. C'est la production d'environ trente secondes de collage et de clics, contre quinze minutes de saisie sujette aux erreurs.

Notez quelques points dans cette sortie. Le champ created_at est typé comme VARCHAR(255) plutôt que DATETIME — nous y reviendrons. Le nom de la table est par défaut users; l'outil vous permet peut-être de le spécifier. Le CREATE TABLE n'inclut pas les contraintes PRIMARY KEY ou NOT NULL — c'est votre travail.

Différences de dialectes à connaître

Le sélecteur de "dialecte SQL" est plus important qu'il n'y paraît. Les différences syntaxiques entre les bases de données sont petites mais elles provoqueront des erreurs si vous choisissez le mauvais.

MySQL utilise des guillemets inversés pour citer les identificateurs : `column_name`. C'est important si votre nom de colonne entre en collision avec un mot réservé MySQL (comme order, key, index ou values). MySQL utilise aussi TINYINT(1) pour les booléens dans les anciens schémas, bien que BOOLEAN fonctionne dans MySQL 5.7+.

PostgreSQL utilise des guillemets doubles pour les identificateurs : "column_name". Il a des types natifs BOOLEAN et TIMESTAMP WITH TIME ZONE. Il a aussi SERIAL et BIGSERIAL pour les clés primaires auto-incrémentées, ce qui diffère de AUTO_INCREMENT de MySQL.

SQLite est permissif sur les types — SQLite utilise "l'affinité de type" plutôt que des types stricts, donc une colonne déclarée comme TEXT peut stocker des entiers et vice versa. Pour la sortie SQLite, vous verrez souvent des noms de type plus simples comme TEXT et INTEGER.

SQL Server utilise NVARCHAR au lieu de VARCHAR pour les chaînes de texte Unicode, et des crochets pour citer les identificateurs : [column_name]. SQL Server utilise aussi BIT pour les valeurs booléennes plutôt que BOOLEAN ou TINYINT.

Si vous importez dans une base de données spécifique, sélectionnez ce dialecte. Si vous exécutez le SQL manuellement et l'adaptez, n'importe quel dialecte vous donne un point de départ utilisable — sachez simplement ce que vous devrez changer.

Déduction de type : ce qui fonctionne et où ça échoue

L'outil est assez bon pour les cas courants :

• 123 en JSON devient INT en SQL
• 123.45 devient FLOAT ou DECIMAL
• "hello" devient VARCHAR(255) ou TEXT
• true / false devient BOOLEAN ou TINYINT(1)
• null devient une colonne nullable, généralement typée comme VARCHAR

Où ça échoue, c'est partout où JSON utilise des chaînes pour représenter des données non-chaînes.

Les numéros de téléphone sont un piège classique. Si votre JSON a "phone": "12345", c'est une chaîne en JSON, et vous obtiendrez VARCHAR(255) — ce qui est correct, car les numéros de téléphone doivent être stockés comme chaînes (zéros initiaux, indicatifs pays avec +, numéros formatés). Mais si quelqu'un a stocké les numéros de téléphone comme entiers nus dans le système source, vous pourriez voir "phone": 12345 et obtenir INT. Alors votre import supprimerait silencieusement les zéros initiaux et le formatage.

Les champs date et heure sortiront presque toujours comme VARCHAR car JSON n'a pas de type de date natif. "2025-01-15T09:23:00Z" n'est qu'une chaîne pour JSON. Si vous avez besoin d'une vraie colonne DATETIME ou TIMESTAMP, changez le type de colonne dans l'instruction CREATE TABLE après la génération. Les données elles-mêmes s'importeront correctement puisque SQL analysera la chaîne ISO 8601 lors de l'insertion dans une colonne TIMESTAMP.

Les IDs qui ressemblent à des nombres sont plus délicats. Un champ id avec la valeur 1042 sera typé comme INT. Ça peut aller — ou votre système utilise peut-être des UUID ou des IDs alphanumériques qui sont simplement tous numériques pour les premières lignes de votre échantillon. Si la ligne 201 a id: "a1b2c3", votre import échouera.

Les grands champs texte seront typés comme VARCHAR(255). Si un champ contient du contenu plus long — corps d'articles, descriptions, données sérialisées — vous devrez changer le type en TEXT ou LONGTEXT dans MySQL, ou TEXT dans PostgreSQL (sans limite de longueur).

Règle générale : examinez toujours l'instruction CREATE TABLE générée avant de l'exécuter. Les instructions INSERT sont généralement correctes, mais la déduction du schéma est là où le jugement humain est nécessaire.

Insertions par lot : pourquoi c'est important

Pour les petits jeux de données — dix ou vingt lignes — ça n'a pas beaucoup d'importance d'insérer une ligne à la fois ou par lots. Pour les jeux de données plus grands, la différence est significative.

Un INSERT ligne par ligne ressemble à ceci :

INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');
INSERT INTO `users` (`id`, `name`, `email`) VALUES (2, 'Ben', 'ben@example.com');
-- ... 198 instructions de plus

Un INSERT par lot ressemble à ceci :

INSERT INTO `users` (`id`, `name`, `email`) VALUES
(1, 'Alice', 'alice@example.com'),
(2, 'Ben', 'ben@example.com'),
(3, 'Sara', 'sara@example.com'),
-- ... jusqu'à 100 lignes
;

INSERT INTO `users` (`id`, `name`, `email`) VALUES
(101, 'David', 'david@example.com'),
-- ... lot suivant
;

La version par lot est plus rapide pour deux raisons. Premièrement, il y a un aller-retour réseau par lot au lieu d'un par ligne. Deuxièmement, la base de données peut optimiser une seule grande écriture mieux que beaucoup de petites — la surcharge de transaction, les mises à jour d'index et la journalisation write-ahead se produisent une fois par instruction plutôt qu'une fois par ligne.

La raison pour laquelle les convertisseurs limitent généralement les lots à 100-500 lignes plutôt que de tout mettre dans une seule instruction est la mémoire et la fiabilité. Une instruction INSERT unique de 10 000 lignes peut toucher les limites de mémoire, être lente à analyser, et si elle échoue à mi-chemin, vous n'avez pas de retour utile sur les lignes problématiques. Les lots plus petits sont plus pratiques.

Ce que l'outil ne fera pas

Être clair sur les limitations vous évite une séance de débogage plus tard.

Pas de clés étrangères. Le convertisseur ne sait rien des relations entre les tables. Si votre JSON a un champ user_id référençant une autre table, vous obtenez une simple colonne INT — pas de contrainte FOREIGN KEY, pas de clause REFERENCES. Vous devrez ajouter cela manuellement.

Pas d'index. Le CREATE TABLE généré n'a pas de définitions d'index. Si vous importez un grand jeu de données et que vous voulez ensuite l'interroger, vous devrez ajouter des définitions INDEX ou UNIQUE INDEX sur les colonnes que vous filtrerez ou joindrez. C'est toujours une étape post-import.

Pas de marquage de clé primaire. L'outil peut créer une colonne id INT mais n'ajoutera pas PRIMARY KEY ou AUTO_INCREMENT. Si vous voulez que id soit une vraie clé primaire auto-incrémentée, ajoutez PRIMARY KEY AUTO_INCREMENT à la définition de cette colonne dans MySQL, ou passez à SERIAL dans PostgreSQL.

Pas de types complexes ou imbriqués. Si la valeur d'un champ est un objet ou un tableau, l'outil ne peut pas l'aplatir en schéma relationnel. Il le sérialisera typiquement en chaîne JSON ou ignorera le champ. Vous devez décider : le stocker comme colonne JSON (MySQL 5.7+ et PostgreSQL supportent les colonnes JSON natives), l'aplatir en colonnes séparées ou le normaliser dans une table séparée.

Pas de logique upsert. Les instructions générées sont des INSERT simples sans gestion des conflits. Si vous les exécutez contre une table qui a déjà des données avec des clés primaires qui se chevauchent, vous obtiendrez des erreurs de violation de contrainte. Pour les imports idempotents, vous auriez besoin de INSERT IGNORE dans MySQL, ON CONFLICT DO NOTHING dans PostgreSQL ou MERGE dans SQL Server — aucun de ceux-ci n'est ajouté automatiquement par l'outil.

Pas de transactions. La sortie n'est pas encapsulée dans BEGIN TRANSACTION / COMMIT. Pour les grands imports, encapsuler le tout dans une transaction est une bonne pratique — si quelque chose échoue à mi-chemin, vous pouvez annuler proprement. Ajoutez-le vous-même autour des instructions générées.

Quand utiliser cet outil plutôt que d'autres options

Le convertisseur JSON vers SQL est le bon outil pour un ensemble spécifique de situations. Ce n'est pas le bon outil pour tout.

Utilisez-le quand :

• Vous avez un import de données ponctuel depuis une source externe
• Vous migrez des données entre bases de données et avez besoin d'un dump SQL rapide
• Vous configurez une base de données de démonstration ou de test avec des données réalistes
• Vous travaillez directement avec SQL sans pile applicative
• Vous devez partager des données avec quelqu'un qui n'a qu'un accès SQL

Utilisez plutôt votre ORM ou outil ETL quand :

• Vous avez besoin de données de seed répétables et versionnées — des outils comme le db seed de Prisma, les fixtures de Django ou les fichiers seed de Rails s'intègrent à votre flux de migration et peuvent être réexécutés en toute sécurité
• L'import est complexe et implique de transformer des données, pas seulement les insérer
• Vous devez gérer les relations et les contraintes de clé étrangère de façon programmatique
• Vous faites ça régulièrement selon un calendrier — écrivez un script ETL approprié ou utilisez un outil comme Apache NiFi, dbt ou même un simple script Python avec pandas et sqlalchemy

Le convertisseur JSON vers SQL est essentiellement un raccourci pour le scénario "j'ai juste besoin de mettre ces données dans une table". Quand le scénario est plus complexe que ça, vous avez besoin d'un outil plus complexe.

Un flux de travail pratique

Voici la séquence qui fonctionne bien :

1. Formatez d'abord votre JSON. Si votre export est minifié, collez-le d'abord dans le formateur JSON. Cela vous permet de revoir la structure et de détecter les problèmes avant la conversion.

2. Vérifiez la structure du tableau. Le convertisseur attend un tableau JSON d'objets où chaque objet a les mêmes clés de niveau supérieur. Si votre export est encapsulé dans un objet racine ({"data": [...]}) plutôt qu'être un tableau nu, extrayez d'abord le tableau.

3. Sélectionnez votre dialecte et collez le JSON. Copiez le SQL généré.

4. Examinez le CREATE TABLE. Avant d'exécuter quoi que ce soit, lisez les types de colonnes et corrigez ceux qui semblent incorrects — en particulier les champs de date, les grands champs texte et tout champ numérique qui devrait réellement être une chaîne.

5. Ajoutez les contraintes dont vous avez besoin. Marquez la clé primaire, ajoutez NOT NULL là où c'est approprié, ajoutez UNIQUE sur les colonnes email, et ajoutez les contraintes FOREIGN KEY nécessaires.

6. Exécutez d'abord le CREATE TABLE, puis les INSERTs. Si la table existe déjà et que vous réimportez, décidez si vous faites d'abord DROP TABLE IF EXISTS ou utilisez une stratégie de résolution de conflits.

7. Vérifiez le nombre de lignes. Après l'import, exécutez SELECT COUNT(*) FROM your_table; et comparez au nombre de lignes dans votre JSON. S'ils correspondent, vous avez terminé.

Formater le SQL en sortie

Le SQL généré est généralement lisible mais pas toujours formaté selon vos standards. Si vous voulez des instructions INSERT formatées de façon cohérente — colonnes alignées, casse cohérente pour les mots-clés — passez la sortie dans le formateur SQL. Ça ne changera pas la sémantique mais rend le SQL plus facile à revoir et à comparer.

En résumé

Écrire des instructions INSERT à la main pour de grands jeux de données JSON est l'une de ces tâches où l'automatisation fait le plus sens. Le convertisseur JSON vers SQL gère la conversion mécanique : il lit votre tableau, déduit les types, génère un schéma et produit des instructions INSERT en lot dans votre dialecte cible.

Les parties qui nécessitent encore votre attention sont la revue du schéma (types, contraintes, index), la gestion des données imbriquées et rendre la logique INSERT idempotente si vous devez la réexécuter. L'outil fait les 90% qui sont purement mécaniques. Les 10% restants sont le jugement de conception de base de données qu'aucune automatisation ne peut remplacer.

Si vous travaillez régulièrement avec des données JSON, deux autres outils valent la peine d'être mis en favoris à côté de celui-ci : le formateur JSON pour revoir et nettoyer vos entrées, et le formateur SQL pour mettre en ordre la sortie générée avant de la valider dans un fichier de migration.