DuckDB analytics : SQLite pour analyse data — tutoriel 2026

Introduction

Il existe une règle non écrite dans le monde de la data : pour analyser des millions de lignes, il faut un cluster Spark, une équipe de data engineers et un budget cloud à cinq chiffres. DuckDB est venu briser cette règle avec une élégance déconcertante. Lancé en 2019 par des chercheurs de la CWI Amsterdam et passé en version stable 1.0 en 2024, DuckDB est aujourd’hui à la version 1.5.2 (avril 2026) et s’est imposé comme la référence des analyses OLAP embarquées : aucun serveur à installer, aucun daemon à maintenir, juste un binaire ou une bibliothèque Python qui se glisse dans votre environnement existant.

La métaphore la plus juste est celle du titre : DuckDB est au monde de l’analytique ce que SQLite est au monde transactionnel. SQLite vous permet de faire tourner une base relationnelle complète dans un fichier unique sans infrastructure — DuckDB vous permet de faire tourner des requêtes analytiques complexes sur des gigaoctets de données depuis votre laptop, votre notebook Jupyter ou votre script Python, sans jamais démarrer un seul serveur. Et contrairement à SQLite, DuckDB est taillé pour la vectorisation SIMD, le traitement multi-colonnes et les formats modernes comme Parquet et Arrow.

Ce tutoriel vous amène de zéro à un pipeline analytique complet : installation du CLI, lecture de fichiers CSV et Parquet, SQL avancé avec window functions et PIVOT, intégration Python/Jupyter, connexion à une base PostgreSQL existante, et export final en Parquet pour votre data lake. Durée estimée : 25 minutes.

Prérequis

• OS : Linux, macOS ou Windows 10/11 (64 bits)
• Python 3.9 ou supérieur (pour l’intégration Python/Jupyter)
• Fichiers de test : un fichier CSV ou Parquet représentatif (des jeux de données publics sont disponibles sur github.com/duckdb/duckdb)
• Optionnel : une instance PostgreSQL accessible en local ou en réseau
• Niveau : intermédiaire — vous connaissez SQL de base et avez déjà utilisé pip
• Temps estimé : ~25 minutes

Étape 1 — DuckDB vs Pandas vs Spark : bien choisir son outil

Avant d’installer quoi que ce soit, prenons deux minutes pour situer DuckDB dans l’écosystème. Ce positionnement vous évitera de passer des heures à tenter d’utiliser le mauvais outil pour le mauvais problème — une erreur fréquente chez les data analysts qui découvrent l’OLAP embarqué.

Pandas est un outil de transformation de données en mémoire : il charge l’intégralité du dataset dans la RAM sous forme de DataFrame, puis applique des opérations colonne par colonne en Python pur. C’est parfait pour des manipulations exploratoires sur des fichiers de moins de quelques centaines de mégaoctets. Au-delà, vous touchez les limites de la mémoire et la lenteur de l’exécution Python.

Apache Spark est un moteur distribué conçu pour des téraoctets de données réparties sur un cluster de machines. Sa force est la scalabilité horizontale quasi illimitée. Sa faiblesse, pour un data analyst PME, est son coût opérationnel : il faut un cluster, un gestionnaire de ressources (YARN, Kubernetes), une équipe pour le maintenir, et un budget cloud significatif. Spark est l’artillerie lourde — pertinente pour des volumes massifs, inadaptée pour l’analyse quotidienne d’un analyste solo.

DuckDB occupe le créneau intermédiaire avec une approche radicalement différente : il exécute des requêtes SQL analytiques directement sur des fichiers locaux (CSV, Parquet, JSON, Arrow) en exploitant toutes les ressources de votre machine — vectorisation SIMD, multi-threading automatique, exécution orientée colonnes. Sur un laptop standard de 8 Go de RAM, DuckDB traite 1 Go de CSV en quelques secondes là où Pandas commence à ramer et où Spark n’est tout simplement pas installé. Pour les volumes compris entre 100 Mo et 100 Go sur une seule machine, DuckDB est presque toujours le meilleur choix.

Le tableau suivant résume les critères de choix :

Pour un data analyst dans une PME sénégalaise ou ivoirienne qui travaille sur des exports de ventes, des données de stock ou des rapports SYSCOHADA, DuckDB est presque systématiquement le bon choix.

Étape 2 — Installer duckdb-cli

DuckDB propose deux modes d’installation principaux : le CLI autonome (un seul binaire, zéro dépendance) et le package Python. Commençons par le CLI qui permet d’explorer vos données interactivement sans écrire une ligne de code.

Sur Linux ou macOS, la méthode la plus simple est le script d’installation officiel fourni par DuckDB. Ouvrez un terminal et exécutez :

# Téléchargement et installation du CLI DuckDB v1.5.2
curl -fsSL https://install.duckdb.org | sh

# Vérification de l'installation
duckdb --version
# Attendu : v1.5.2

Le script détecte votre architecture (x86_64 ou ARM/Apple Silicon) et installe le bon binaire dans /usr/local/bin. Sur macOS avec Homebrew, vous pouvez également faire brew install duckdb pour bénéficier des mises à jour automatiques via brew upgrade.

Sur Windows, rendez-vous sur duckdb.org/install pour télécharger le fichier duckdb_cli-windows-amd64.zip, décompressez-le dans un dossier de votre PATH (par exemple C:\Windows\System32 ou un dossier dédié ajouté manuellement au PATH système), puis ouvrez PowerShell et vérifiez avec duckdb --version. Notez que Windows requiert le Microsoft Visual C++ Redistributable — si vous obtenez une erreur DLL, installez-le depuis le site Microsoft.

Pour l’installation Python (nécessaire pour les étapes 5 et suivantes), un simple pip suffit :

# Installation du package Python DuckDB
pip install duckdb

# Optionnel : installer aussi les intégrations Jupyter et Pandas
pip install duckdb jupyterlab pandas pyarrow

La bibliothèque Python DuckDB (duckdb 1.5.2) ne requiert aucune dépendance système externe — elle embarque le moteur entier comme SQLite le fait. L’installation pip seule suffit pour aller jusqu’à l’étape 7.

Étape 3 — Lire CSV, Parquet et JSON directement

L’une des fonctionnalités les plus séduisantes de DuckDB est sa capacité à interroger des fichiers directement par leur chemin, sans aucune étape d’import préalable. C’est là que la métaphore SQLite s’arrête : SQLite requiert d’importer les données dans une base avant de les requêter — DuckDB traite les fichiers comme des tables virtuelles, directement.

Ouvrez le CLI avec la commande duckdb sans argument (mode en mémoire, parfait pour l’exploration) :

-- Lire un CSV directement — DuckDB détecte automatiquement les types et le séparateur
SELECT * FROM read_csv_auto('ventes_2025.csv') LIMIT 10;

-- Compter les lignes sans charger tout le fichier
SELECT COUNT(*) FROM read_csv_auto('ventes_2025.csv');

-- Lire un Parquet
SELECT * FROM read_parquet('transactions.parquet') LIMIT 5;

-- Lire tous les fichiers Parquet d'un dossier (glob)
SELECT * FROM read_parquet('data/annuel/*.parquet') LIMIT 10;

-- Lire un JSON (array ou JSON-lines)
SELECT * FROM read_json_auto('produits.json') LIMIT 10;

La fonction read_csv_auto est remarquablement intelligente : elle détecte le séparateur (, ou ; ou tabulation), l’encodage, les types de colonnes (INTEGER, DATE, DOUBLE) et même la présence d’un en-tête. Sur un fichier CSV de 500 000 lignes, cette détection est quasi-instantanée. Si vous devez forcer des paramètres, des options explicites sont disponibles :

-- Forcer le séparateur et l'encodage (utile pour exports Excel français)
SELECT * FROM read_csv('export_compta.csv',
  sep=';',
  header=true,
  encoding='latin1'
) LIMIT 10;

Vous pouvez aussi créer des vues persistantes sur ces fichiers pour simplifier les requêtes suivantes. Dans une session DuckDB, CREATE VIEW ventes AS SELECT * FROM read_csv_auto('ventes_2025.csv'); vous permettra ensuite d’écrire SELECT * FROM ventes sans répéter le chemin du fichier à chaque fois.

Étape 4 — SQL analytics avancé : window functions et PIVOT

C’est ici que DuckDB révèle tout son potentiel analytique. Les window functions (fonctions de fenêtre) et la clause PIVOT permettent de réaliser en quelques lignes SQL des analyses que Pandas nécessiterait des dizaines de lignes de code pour reproduire. DuckDB supporte l’intégralité du SQL analytique standard — une compatibilité bien supérieure à celle de SQLite.

Commençons par les window functions, qui permettent de calculer des agrégats sur une partition de lignes sans effacer les lignes individuelles. Un cas classique en PME : calculer le chiffre d’affaires cumulé par mois pour chaque vendeur.

-- Window function : CA cumulé par vendeur, ordonné par date
SELECT
  vendeur,
  date_vente,
  montant,
  SUM(montant) OVER (
    PARTITION BY vendeur
    ORDER BY date_vente
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS ca_cumule,
  -- Rang de chaque vente dans la période, par vendeur
  RANK() OVER (PARTITION BY vendeur ORDER BY montant DESC) AS rang_vente
FROM read_csv_auto('ventes_2025.csv');

La clause PARTITION BY vendeur indique que le calcul repart de zéro pour chaque vendeur. ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW définit la fenêtre glissante depuis la première ligne jusqu’à la ligne courante — c’est la définition du cumulé. Le résultat conserve chaque ligne de vente individuelle, enrichie de deux colonnes calculées.

Pour le PIVOT (transformation de lignes en colonnes, très utile pour les tableaux croisés), DuckDB propose une syntaxe claire :

-- PIVOT : CA mensuel par produit (lignes = produits, colonnes = mois)
PIVOT (
  SELECT produit, mois, SUM(montant) AS ca
  FROM read_csv_auto('ventes_2025.csv')
  GROUP BY produit, mois
)
ON mois
USING SUM(ca)
ORDER BY produit;

Ce PIVOT prend une table longue (une ligne par combinaison produit/mois) et la transforme en table large (une ligne par produit, une colonne par mois). C’est exactement le tableau croisé que vous pourriez chercher à faire dans Excel — sauf qu’ici vous travaillez sur des millions de lignes en SQL standard, sans risque de crash tableur.

D’autres fonctions analytiques particulièrement utiles en contexte PME : LAG() et LEAD() pour comparer une valeur avec la période précédente ou suivante, NTILE(4) pour segmenter les clients en quartiles, et PERCENT_RANK() pour calculer le percentile de chaque transaction.

Étape 5 — DuckDB en Python pour notebooks Jupyter

L’intégration Python de DuckDB est l’un de ses atouts majeurs : elle permet d’utiliser DuckDB comme moteur SQL haute performance directement dans un notebook Jupyter, tout en interagissant facilement avec les DataFrames Pandas existants. Vous n’avez pas à choisir entre SQL et Python — DuckDB fait le pont entre les deux.

Commencez par créer une connexion DuckDB dans votre notebook :

import duckdb
import pandas as pd

# Connexion en mémoire (données non persistées entre sessions)
con = duckdb.connect()

# Ou connexion à un fichier DuckDB persistant
# con = duckdb.connect('mon_analyse.duckdb')

La connexion en mémoire est idéale pour l’exploration : toutes les données et vues créées disparaissent à la fermeture du notebook. La connexion fichier (mon_analyse.duckdb) persiste les tables et les résultats entre sessions, utile pour des pipelines récurrents.

Vous pouvez maintenant requêter directement vos fichiers et récupérer les résultats sous forme de DataFrame Pandas :

# Requête SQL sur un CSV, résultat en DataFrame Pandas
df = con.execute("""
    SELECT
        vendeur,
        SUM(montant) AS ca_total,
        COUNT(*) AS nb_ventes,
        AVG(montant) AS panier_moyen
    FROM read_csv_auto('ventes_2025.csv')
    GROUP BY vendeur
    ORDER BY ca_total DESC
""").df()

print(df.head(10))

La méthode .df() convertit le résultat DuckDB en DataFrame Pandas. Vous pouvez ensuite utiliser matplotlib, seaborn ou plotly pour visualiser le résultat — DuckDB s’occupe du heavy lifting SQL, Pandas du post-traitement léger, et votre bibliothèque de visualisation préférée du rendu graphique.

L’intégration va dans les deux sens : DuckDB peut aussi requêter un DataFrame Pandas existant directement par son nom de variable :

# DataFrame Pandas existant dans votre environnement
df_clients = pd.read_csv('clients.csv')

# DuckDB peut requêter df_clients par son nom — magie de l'intégration Arrow
resultat = con.execute("""
    SELECT pays, COUNT(*) AS nb_clients
    FROM df_clients
    GROUP BY pays
    ORDER BY nb_clients DESC
""").df()

DuckDB accède au DataFrame Pandas via Apache Arrow en mémoire partagée, sans copie de données. Pour les notebooks avec des données volumineuses, c’est un gain de mémoire et de temps très significatif.

Étape 6 — Connexion Postgres via l’extension postgres

DuckDB n’est pas seulement un outil de fichiers plats : il peut se connecter à une base PostgreSQL existante et la requêter comme si ses tables étaient des fichiers locaux. C’est utile quand votre application de production tourne sur PostgreSQL mais que vous voulez faire des analyses lourdes sans impacter la base de production — DuckDB interroge PostgreSQL en lecture seule, tirant les données via libpq, puis les traite localement avec son moteur vectorisé.

L’extension postgres (anciennement appelée postgres_scanner) est une extension officielle DuckDB. Installez-la et chargez-la depuis le CLI ou depuis Python :

-- Depuis le CLI DuckDB : installer l'extension (une seule fois)
INSTALL postgres;
-- Charger l'extension pour la session courante
LOAD postgres;

-- Attacher la base PostgreSQL distante
ATTACH 'host=localhost port=5432 dbname=erp_pme user=analyste password=xxx'
  AS pg_erp (TYPE postgres, READ_ONLY);

-- Lister les tables disponibles dans la base attachée
SHOW TABLES;

-- Requêter une table PostgreSQL comme une table locale
SELECT * FROM pg_erp.public.factures LIMIT 10;

-- Jointure entre une table PostgreSQL et un fichier CSV local
SELECT
  f.id_facture,
  f.montant_ht,
  c.nom_client,
  c.pays
FROM pg_erp.public.factures f
JOIN read_csv_auto('clients_export.csv') c ON f.id_client = c.id
LIMIT 100;

La commande ATTACH établit la connexion et rend toutes les tables du schéma public immédiatement accessibles. Le préfixe pg_erp. permet de distinguer les tables PostgreSQL des tables DuckDB locales dans vos requêtes. L’option READ_ONLY garantit que DuckDB ne peut pas écrire dans votre base de production — une sécurité importante à ne pas omettre.

La jointure de la dernière requête illustre le cas d’usage le plus puissant : croiser des données PostgreSQL de production avec des fichiers CSV exportés depuis d’autres systèmes (un ERP local, un export Excel des RH) sans aucune ETL intermédiaire. DuckDB orchestre la récupération depuis les deux sources, optimise le plan d’exécution et retourne le résultat en quelques secondes.

Étape 7 — Export vers Parquet pour data lake

Une fois vos analyses réalisées, vous voudrez souvent persister les résultats dans un format efficace pour une réutilisation future. DuckDB supporte l’export natif vers Parquet, le format colonnaire standard des data lakes modernes. Un fichier Parquet est en moyenne 10 fois plus compact qu’un CSV équivalent grâce à la compression par colonne, et il conserve les types de données (dates, entiers, flottants) sans ambiguïté.

La syntaxe d’export est simple et s’applique à n’importe quelle requête :

-- Exporter le résultat d'une requête analytique en Parquet
COPY (
  SELECT
    vendeur,
    strftime('%Y-%m', date_vente) AS mois,
    SUM(montant) AS ca_mensuel,
    COUNT(*) AS nb_ventes
  FROM read_csv_auto('ventes_2025.csv')
  GROUP BY vendeur, strftime('%Y-%m', date_vente)
  ORDER BY vendeur, mois
) TO 'ca_mensuel_par_vendeur.parquet' (FORMAT parquet);

-- Options avancées : compression snappy (défaut) ou zstd, taille des row groups
COPY (
  SELECT * FROM read_csv_auto('transactions_2025.csv')
) TO 'transactions_2025.parquet' (
  FORMAT parquet,
  COMPRESSION zstd,
  ROW_GROUP_SIZE 100000
);

-- Partitionner automatiquement par colonne (pour les data lakes)
COPY (
  SELECT * FROM read_csv_auto('ventes_2025.csv')
) TO 'data/ventes_partitionne' (
  FORMAT parquet,
  PARTITION_BY (annee, trimestre)
);

La compression zstd est recommandée pour les archives longue durée — elle compresse plus que snappy au prix d’un temps de compression légèrement plus élevé, compensé largement par les économies de stockage. La partition PARTITION_BY (annee, trimestre) crée une arborescence de dossiers (data/ventes_partitionne/annee=2025/trimestre=Q1/...) compatible avec Apache Hive et lisible par n’importe quel outil data lake (Spark, Athena, BigQuery Storage, DuckDB lui-même).

Depuis Python, la même opération s’écrit avec la méthode write_parquet de PyArrow ou directement via la connexion DuckDB :

# Export Parquet via Python
con.execute("""
  COPY (
    SELECT * FROM read_csv_auto('ventes_2025.csv')
  ) TO 'ventes_2025.parquet' (FORMAT parquet, COMPRESSION zstd)
""")

# Vérification : re-lire le fichier exporté
df_check = con.execute("SELECT COUNT(*) FROM read_parquet('ventes_2025.parquet')").df()
print(df_check)

Erreurs fréquentes

Adaptation au contexte ouest-africain

DuckDB est particulièrement bien adapté aux contraintes du terrain en Afrique de l’Ouest, et ce pour plusieurs raisons concrètes que nous allons détailler.

Laptop modeste, résultats professionnels. Un analyste data dans une PME dakaroise ou abidjanaise dispose rarement d’un serveur dédié pour l’analytique. Son outil de travail est souvent un laptop de 8 Go de RAM sous Windows, éventuellement partagé avec d’autres applications. DuckDB tire profit de ce matériel de façon spectaculaire : sur une machine de cette gamme, une requête d’agrégation sur un fichier CSV d’1 Go — la taille typique d’un export annuel de transactions — s’exécute en 2 à 8 secondes. Le même fichier ferait saturer Pandas ou nécessiterait d’attendre plusieurs minutes. DuckDB utilise automatiquement tous les cœurs disponibles et un mécanisme de spilling sur disque pour les opérations qui dépassent la RAM, sans aucune configuration.

Zéro infrastructure, zéro serveur. Pas besoin de demander un serveur à la DSI, de négocier un budget cloud, d’attendre une validation projet pour démarrer. DuckDB s’installe en 30 secondes sur n’importe quelle machine et fonctionne immédiatement. Pour les PME sans département IT structuré — la réalité de la grande majorité des entreprises ouest-africaines — c’est déterminant.

Export SYSCOHADA en Parquet. Le plan comptable SYSCOHADA (utilisé au Sénégal, en Côte d’Ivoire, au Mali, au Burkina Faso, au Togo, au Bénin et dans sept autres pays de la zone franc) génère des données de comptes structurées que les cabinets comptables exportent généralement en CSV ou en Excel. DuckDB permet de charger ces exports, de les croiser avec d’autres sources (données de vente, stock, RH), et d’exporter le résultat en Parquet pour archivage ou transmission à un auditeur. Un fichier Parquet de données SYSCOHADA est 5 à 15 fois plus compact qu’un CSV équivalent, ce qui réduit les coûts de stockage et simplifie la transmission par email ou par WhatsApp sur des connexions à faible débit.

Fonctionnement hors ligne. Les coupures de courant et les interruptions de connexion internet sont une réalité quotidienne. DuckDB fonctionne entièrement en local — pas de cloud, pas d’API distante, pas de token d’authentification à renouveler. Une fois installé et les extensions téléchargées, il fonctionne sans réseau. Les données restent sur la machine de l’analyste, ce qui répond aussi aux préoccupations légitimes sur la confidentialité des données financières.

Coût total nul. DuckDB est open source sous licence MIT — gratuit pour tout usage commercial. Aucune licence à acheter, aucun abonnement cloud, aucun coût d’utilisation à l’exécution. Pour des PME dont la trésorerie est serrée, c’est un argument décisif face aux solutions SaaS de BI ou aux bases cloud facturées à la requête.

Tutoriels frères

Ce tutoriel fait partie du cluster Bases de données spécialisées. D’autres tutoriels du même cluster vous permettront d’approfondir des besoins complémentaires :

• ClickHouse : analytics haute performance pour données volumineuses — tutoriel 2026 — quand vos volumes dépassent ce que DuckDB peut traiter seul sur une machine, ClickHouse prend le relais avec une architecture distribuée.
• TimescaleDB : séries temporelles sur PostgreSQL — tutoriel 2026 — si vos données sont des métriques horodatées (IoT, capteurs, logs), TimescaleDB complète avantageusement DuckDB pour le stockage et la requête en temps réel.
• pgvector : recherche sémantique et embeddings dans PostgreSQL — tutoriel 2026 — pour les cas d’usage IA nécessitant des recherches vectorielles sur vos données.

Pour aller plus loin

• Retour au pilier : Bases de données modernes 2026 : DuckDB, ClickHouse, TimescaleDB, pgvector
• Documentation officielle : duckdb.org/docs/stable — la référence primaire pour toutes les fonctions SQL, extensions et guides par format de fichier
• Code source et releases : github.com/duckdb/duckdb — changelog complet, issues et discussions de la communauté
• Extensions officielles : duckdb.org/docs/stable/core_extensions/overview — liste complète des extensions maintenues par l’équipe DuckDB (postgres, sqlite, httpfs, json, parquet…)
• Prochain tutoriel conseillé dans le cluster : ClickHouse analytics haute performance pour passer à l’échelle suivante

FAQ

Site réalisé par [ITS] ITSkillsCenter — Formation IT professionnelle en Afrique de l’Ouest