---
title: "Passer une base SQLite à une autre version"
description: "Convertissez un fichier .db ou un dump SQLite en script qui se charge sur SQLite 3.31 et suivants, avec les mêmes tables, clés et données, et un rapport."
canonical: https://intosql.com/fr/sqlite-en-sqlite
last_updated: 2026-10-15
---

# Passer une base SQLite à une autre version

Déposez un fichier de base SQLite (.db, .sqlite, .sqlite3) ou le SQL qu'écrit .dump de sqlite3, et téléchargez un script qui se charge sur SQLite 3.31 et suivants. Chaque colonne garde son type déclaré et sa collation, STRICT est retiré pour que les versions plus anciennes acceptent les tables, et chaque changement figure dans le rapport.

[Guide de migration de SQLite vers SQLite](https://intosql.com/docs/migrations/sqlite-to-sqlite)

[Types de données de SQLite vers SQLite](https://intosql.com/docs/types/sqlite-to-sqlite)

## Ce qui change entre le fichier et le script

Chaque ligne est une règle appliquée par le convertisseur, avec la ligne de rapport qu'il écrit quand la règle change quelque chose dans vos données.

| Dans le fichier | Dans le script | Ligne du rapport |
| --- | --- | --- |
| declared types (any text: VARCHAR(255), DATETIME, BOOLEAN, JSON or none) | le type auquel chaque valeur de la colonne correspond |  |
| BOOLEAN, BOOL | INTEGER 0 ou 1 avec un CHECK |  |
| TEXT, VARCHAR(n), CHAR(n), CLOB | le type déclaré, gardé tel quel |  |
| DECIMAL(p,s), NUMERIC | le type exact si chaque valeur y tient, sinon un double |  |
| BLOB, and columns holding bytes | BLOB |  |
| DATE, DATETIME, TIMESTAMP holding ISO 8601 text | DATE, DATETIME en texte ISO 8601 |  |
| JSON holding JSON text | TEXT |  |
| Infinity in REAL columns | 9e999, l'infini propre à SQLite |  |
| INTEGER PRIMARY KEY, AUTOINCREMENT | INTEGER PRIMARY KEY, AUTOINCREMENT conservé |  |
| COLLATE NOCASE | COLLATE NOCASE |  |
| generated columns | colonnes générées, STORED ou VIRTUAL comme dans la source |  |
| generated columns with functions IntoSQL doesn't write, and the || operator | une colonne simple | `generated_not_translated` |
| defaults with functions IntoSQL doesn't write (strftime, randomblob) | aucune valeur par défaut | `default_not_translated` |
| CHECK constraints | traduites |  |
| CHECK constraints with functions IntoSQL doesn't write | non créée | `check_skipped` |
| partial and expression indexes | non créée | `index_skipped` |
| foreign keys (unenforced unless PRAGMA foreign_keys=ON) | les mêmes clés étrangères, listées par PRAGMA foreign_key_check |  |
| foreign keys to tables the dump doesn't create | non créée | `foreign_key_skipped` |
| primary keys holding NULL, and NOT NULL columns with values that become NULL | NOT NULL retiré | `not_null_relaxed` |
| views, triggers and virtual tables (FTS, R*Tree) | listés dans le rapport | `not_converted_objects` |
| dumps without CREATE TABLE (--data-only) | types déduits des valeurs | `no_schema` |
| expressions in INSERT values other than the text functions dumps write | NULL | `expression_value` |
| NUL characters in text | conservé |  |
| text that isn't valid UTF-8 | les octets invalides deviennent le caractère de remplacement | `invalid_utf8_replaced` |
| text decoded twice (ñ) | copié tel quel | `mojibake_suspected` |

## Charger le script dans SQLite

Le script crée les tables, copie les lignes, puis ajoute les clés, les index et les clés étrangères ; il se charge donc vite et s'arrête à la première erreur.

```shell
sqlite3 -bail mydb.sqlite < sqlite.sqlite.sql
```

Les clés étrangères sont déclarées dans chaque table et les lignes se chargent sans vérification des clés étrangères. Le script liste ensuite toute ligne qui pointe vers une ligne qui n'existe pas, au lieu d'échouer à mi-chemin.

Pour un gros dump, chargez-le dans un nouveau fichier sur un disque local. Le script charge tout dans une seule transaction sans synchronisation, il va donc à la vitesse du disque, et un chargement interrompu ne laisse aucune table partielle.

La ligne de commande charge le fichier directement dans une base SQLite, sans écrire de script. C'est gratuit.

## Faire le dump SQLite pour un meilleur résultat

Le convertisseur lit ce que contient le dump. Ces options y gardent davantage de vos données :

- Le fichier de base de données lui-même se convertit tel quel, lu page par page dans votre navigateur. Fermez d'abord l'application qui y écrit, pour qu'aucun changement ne reste dans son fichier -wal.
- sqlite3 app.db .dump > app.sql écrit la même base de données en SQL, qui se convertit aussi, en .sql ou .sql.gz.
- DB Browser for SQLite écrit ce SQL avec File, Export, Database to SQL file, tout comme iterdump() de Python.

## Ce qui n'est pas converti

Les vues, triggers, procédures, fonctions et autres objets écrits dans le propre langage de SQLite sont listés par nom dans le rapport, jamais supprimés en silence, pour que vous vérifiiez chacun face à la version de SQLite cible avant de le recréer.

## Questions sur le passage de SQLite d'une version à l'autre

### Mon dump est-il envoyé ?

Non. Le convertisseur s'exécute dans votre navigateur et lit le dump depuis votre disque par morceaux ; il ne quitte donc jamais votre ordinateur. L'application de bureau et la ligne de commande convertissent aussi sur votre ordinateur.

### Quelle taille peut avoir le dump ?

Le convertisseur ne garde jamais tout le dump en mémoire : il lit le fichier deux fois, par plages, et écrit le script au fur et à mesure. Les dumps de plusieurs gigaoctets se convertissent dans le navigateur, dans l'application de bureau et avec la ligne de commande.

### Puis-je convertir le fichier .db lui-même ?

Oui. Déposez le fichier .db, .sqlite ou .sqlite3 : il est lu dans votre navigateur et jamais envoyé. Le texte avec des caractères NUL et chaque chiffre d'un double arrivent tels qu'ils sont stockés, ce qu'un .dump peut tronquer.

### De quelles versions de SQLite le dump peut-il venir ?

Les fichiers de base de données de SQLite 3.0 et après, en UTF-8 ou UTF-16, et les dumps du .dump du shell sqlite3 ou de iterdump() de Python. Chaque fichier et dump de test vient de sqlite3 3.31 à 3.54, tables STRICT et WITHOUT ROWID comprises, et est comparé à sa source cellule par cellule.

### Comment les types de colonnes sont-ils décidés quand SQLite ne les impose pas ?

Chaque colonne garde son type déclaré, tout comme COLLATE NOCASE et RTRIM. STRICT est omis, donc le script se charge sur toutes les versions depuis 3.31.

### INTEGER PRIMARY KEY et AUTOINCREMENT sont-ils conservés ?

Oui. INTEGER PRIMARY KEY et AUTOINCREMENT restent tels quels, et sqlite_sequence reprend là où le dump l'a laissé.

### Et les vues et les déclencheurs ?

Ils sont listés par nom dans le rapport et ne sont pas convertis, pour que vous puissiez les recréer une fois les tables en place.

### Sur quelles versions de SQLite le script se charge-t-il ?

SQLite 3.31 et versions ultérieures. Chaque fichier et dump de test se charge sur 3.31 et 3.54, et s'arrête à la première erreur en cas de problème.

## Depuis SQLite

- [SQLite vers PostgreSQL](https://intosql.com/fr/sqlite-en-postgresql)
- [SQLite vers MySQL](https://intosql.com/fr/sqlite-en-mysql)
- [SQLite vers MariaDB](https://intosql.com/fr/sqlite-en-mariadb)
- [SQLite vers SQL Server](https://intosql.com/fr/sqlite-en-sql-server)
- [SQLite vers Oracle](https://intosql.com/fr/sqlite-en-oracle)

## Vers SQLite

- [MySQL vers SQLite](https://intosql.com/fr/mysql-en-sqlite)
- [MariaDB vers SQLite](https://intosql.com/fr/mariadb-en-sqlite)
- [PostgreSQL vers SQLite](https://intosql.com/fr/postgresql-en-sqlite)
- [SQL Server vers SQLite](https://intosql.com/fr/sql-server-en-sqlite)
- [Oracle vers SQLite](https://intosql.com/fr/oracle-en-sqlite)

## Guide et toutes les paires

- [Guide de migration de SQLite vers SQLite](https://intosql.com/docs/migrations/sqlite-to-sqlite)
- [Types de données de SQLite vers SQLite](https://intosql.com/docs/types/sqlite-to-sqlite)
- [Toutes les paires de bases de données](https://intosql.com/fr/migration-de-base-de-donnees)