Convertisseur CSV vers SQL

Passer d’un fichier CSV à une table SQL est une corvée qui revient sans arrêt : écrire le CREATE TABLE à la main, deviner le bon type pour chaque colonne, échapper les apostrophes, gérer les cellules vides. L’outil ci-dessus fait tout ça en un collage et vous rend un CREATE TABLE propre plus les INSERT correspondants, pour MySQL, PostgreSQL, SQL Server ou SQLite. La conversion tourne entièrement dans votre navigateur : aucun fichier n’est envoyé sur un serveur.

Cet article explique ce qui se passe sous le capot — utile si vous voulez comprendre, ajuster ou contester les types choisis.

Comment convertir un CSV en SQL

1. Collez votre CSV, ou importez un fichier .csv / .tsv.
2. Choisissez le dialecte SQL de votre base cible.
3. Ajustez si besoin : nom de la table, présence d’en-têtes, clé primaire id, inférence du NOT NULL, génération des INSERT.
4. Cliquez sur Convertir, puis copiez le SQL ou téléchargez le .sql.

Le délimiteur est détecté automatiquement, y compris le point-virgule des exports Excel français. Vous pouvez le forcer si la détection se trompe.

Comment les types SQL sont inférés

L’outil analyse chaque colonne en balayant toutes ses valeurs, puis choisit le type le plus strict qui les accepte toutes :

• Entiers → INT, sauf si une valeur dépasse la plage des entiers signés 32 bits (±2 147 483 647) : dans ce cas BIGINT. C’est le piège classique des identifiants et des grands compteurs.
• Décimaux → DECIMAL(p, s) (ou NUMERIC en PostgreSQL), où la précision et l’échelle sont calculées à partir du plus grand nombre de chiffres observé avant et après la virgule. La virgule décimale française est acceptée et convertie en point.
• Dates au format ISO (aaaa-mm-jj) ou français (jj/mm/aaaa) → DATE. Avec une heure → DATETIME (TIMESTAMP en PostgreSQL, DATETIME2 en SQL Server).
• Booléens textuels (true/false, oui/non, vrai/faux, yes/no) → BOOLEAN en PostgreSQL, BIT en SQL Server, TINYINT(1) en MySQL.
• Reste → VARCHAR dimensionné sur la longueur réelle maximale (paliers 10 / 25 / 50 / 100 / 150 / 200 / 255), ou TEXT au-delà de 255 caractères.

Choix assumé : les colonnes ne contenant que des 0 et des 1 restent en INT, pas en booléen. C’est trop ambigu pour trancher à votre place — un 0/1 peut être un vrai booléen comme une note ou un flag numérique.

Les pièges classiques du CSV vers SQL (et comment ils sont gérés)

La plupart des conversions ratées viennent toujours des mêmes points. Voici ceux que l’outil traite pour vous :

• Le délimiteur. Excel en configuration française exporte en point-virgule, pas en virgule. Beaucoup d’outils anglophones se cassent là-dessus et vous rendent une seule colonne. La détection lit la première ligne et choisit le bon séparateur.
• Les virgules dans les champs. Un champ entre guillemets comme "Durand, Alice" ne doit pas être découpé. Le parsing suit la norme RFC 4180, guillemets échappés "" compris.
• Les apostrophes. Un O'Brien casse un INSERT naïf. Chaque apostrophe est doublée (O''Brien), ce qui produit du SQL valide et évite les erreurs de syntaxe.
• Vide ≠ chaîne vide. Une cellule vide devient NULL, pas ''. Et une colonne sans aucune valeur manquante peut recevoir NOT NULL automatiquement.
• Le format de date. Un jj/mm/aaaa est normalisé en aaaa-mm-jj dans les INSERT, sinon la plupart des SGBD le rejettent.
• Le VARCHAR(255) réflexe. Inutile de mettre 255 partout : la taille est calée sur le contenu réel, ce qui donne un schéma plus honnête et plus facile à relire.

MySQL, PostgreSQL, SQL Server, SQLite : ce qui change

Le même CSV ne produit pas exactement le même SQL selon la cible. Les différences portent sur les types, l’auto-incrément et la façon de délimiter les identifiants :

Détail qui a son importance : en SQL Server, le texte est généré en NVARCHAR (Unicode), donc vos accents et caractères spéciaux passent sans réglage de collation. C’est le genre de piège qui coûte une demi-journée quand on l’apprend en production.

Pourquoi tout se passe dans le navigateur

Le fichier n’est jamais téléversé. La conversion s’exécute en JavaScript dans votre onglet, ce qui règle deux choses d’un coup. La confidentialité d’abord : un export métier, un extrait client ou un fichier RH n’a aucune raison de transiter par un serveur tiers, et cela vous évite un point de friction RGPD inutile. La rapidité ensuite : pas d’aller-retour réseau, pas d’attente. Vous pouvez même couper votre connexion, l’outil continue de fonctionner.

Questions fréquentes

Mes données sont-elles envoyées quelque part ?

Non. Tout est traité localement dans votre navigateur, en JavaScript. Aucun fichier n’est téléversé, rien n’est stocké côté serveur. Vous pouvez le vérifier en coupant votre connexion : la conversion marche toujours.

L’outil fonctionne-t-il avec un export Excel ?

Oui. Enregistrez votre feuille au format CSV depuis Excel, puis collez-la ou importez le fichier. Le point-virgule utilisé par Excel en français est reconnu automatiquement.

Quel dialecte dois-je choisir ?

Celui du SGBD où vous allez exécuter le script : MySQL/MariaDB, PostgreSQL, SQL Server ou SQLite. Le type des colonnes, l’auto-incrément et la façon de délimiter les noms changent selon la cible, donc le bon choix évite des erreurs à l’exécution.

Peut-on générer uniquement le CREATE TABLE ?

Oui. Décochez « Générer les INSERT » pour ne récupérer que la structure de la table.

L’outil gère-t-il les gros fichiers ?

Il traite sans problème de quelques lignes à plusieurs dizaines de milliers. Au-delà de quelques centaines de milliers de lignes, un import natif est plus adapté : LOAD DATA INFILE sur MySQL, COPY sur PostgreSQL, bcp ou BULK INSERT sur SQL Server.

Comment sont choisis les types de chaque colonne ?

L’outil balaie toutes les valeurs d’une colonne et retient le type le plus strict qui les accepte : entier, décimal, date, booléen, sinon texte de taille calibrée. Les détails sont expliqués dans la section « Comment les types SQL sont inférés » ci-dessus.