Pourquoi les séries temporelles changent tout en 2026
Une série temporelle, c’est simplement une suite de mesures horodatées : la température d’une chambre froide à Dakar toutes les minutes, le nombre de transactions Orange Money par seconde au Burkina, la latence de ton API e-commerce, le niveau de stock d’un entrepôt à Abidjan, la consommation électrique d’un cybercafé à Conakry. Ces données partagent une structure commune : (timestamp, valeur, tags). Elles sont massives en volume (un capteur qui émet toutes les 10 secondes produit 8,6 millions de points par an), mais simples en structure. Les bases relationnelles classiques s’effondrent au-delà de quelques dizaines de millions de lignes, sauf si elles sont spécialisées.
TimescaleDB est l’extension PostgreSQL qui résout exactement ce problème. Elle ajoute à PostgreSQL la notion d’hypertable : une table virtuelle qui partitionne automatiquement tes données par tranches de temps, sans aucune intervention manuelle. Tu écris du SQL standard, mais sous le capot tu obtiens des performances comparables à InfluxDB ou Prometheus, avec en bonus tout l’écosystème PostgreSQL (joins, transactions ACID, GIS via PostGIS, recherche full-text, etc.).
Ce tutoriel s’inscrit dans le guide général Bases de données modernes 2026. Tu y apprendras à installer TimescaleDB sur un VPS Hetzner CX22, créer ta première hypertable, ingérer des millions de points sans saturer ton serveur, et construire des continuous aggregates pour des dashboards Grafana réactifs.
Prérequis
- VPS Hetzner Cloud CX22 minimum (4,15 € HT/mois ≈ 2 700 F CFA). Pour une production avec 10+ capteurs émettant chaque seconde, vise un CX32 (8 Go RAM).
- Ubuntu 22.04 LTS ou 24.04 LTS, fraîchement installé.
- Compétences SQL de base (CREATE TABLE, INSERT, SELECT, JOIN).
- Notion de PostgreSQL (utilisateurs, bases, rôles). Si tu débutes, suis d’abord le module PostgreSQL de notre guide self-hosting Coolify + Hetzner.
- Connexion SSH stable. Le téléchargement de TimescaleDB pèse ~50 Mo, soit moins de 5 minutes en 4G partagée depuis Bamako ou Abidjan.
Installation pas-à-pas
Le dépôt officiel Timescale fournit des paquets pour Ubuntu, Debian, RHEL et Alpine. On va l’utiliser plutôt qu’une compilation manuelle, plus rapide et plus sécurisée :
# Ajout du dépôt PostgreSQL officiel (PGDG)
sudo apt install -y curl gnupg lsb-release
sudo sh -c 'echo "deb https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo gpg --dearmor -o /usr/share/keyrings/pgdg.gpg
# Ajout du dépôt Timescale
sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/timescale.gpg] https://packagecloud.io/timescale/timescaledb/ubuntu/ $(lsb_release -cs) main' > /etc/apt/sources.list.d/timescaledb.list"
curl -fsSL https://packagecloud.io/timescale/timescaledb/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/timescale.gpg
# Installation PostgreSQL 16 + TimescaleDB
sudo apt update
sudo apt install -y postgresql-16 timescaledb-2-postgresql-16
# Tuning automatique des paramètres PostgreSQL pour TimescaleDB
sudo timescaledb-tune --quiet --yes
sudo systemctl restart postgresqlL’outil timescaledb-tune est précieux : il ajuste shared_buffers, effective_cache_size, work_mem et 10 autres paramètres en fonction de la RAM disponible sur ton VPS. Sur un CX22 (4 Go RAM), il configure typiquement 1 Go de shared_buffers et 3 Go d’effective_cache_size, ce qui est optimal.
Créer ta première hypertable
Connecte-toi à PostgreSQL et active TimescaleDB sur une nouvelle base de données :
sudo -u postgres psql
-- Création de la base et de l'utilisateur
CREATE DATABASE iot_pme;
CREATE USER pme WITH PASSWORD 'mot-de-passe-fort';
GRANT ALL PRIVILEGES ON DATABASE iot_pme TO pme;
\c iot_pme
-- Activation TimescaleDB
CREATE EXTENSION IF NOT EXISTS timescaledb;
-- Table classique de mesures de capteur
CREATE TABLE mesures_capteurs (
time TIMESTAMPTZ NOT NULL,
capteur_id TEXT NOT NULL,
valeur DOUBLE PRECISION,
unite TEXT,
site TEXT -- ex: 'dakar-entrepot-1', 'abidjan-frigo-3'
);
-- Conversion en hypertable
SELECT create_hypertable('mesures_capteurs', 'time');
-- Index utiles
CREATE INDEX ON mesures_capteurs (capteur_id, time DESC);
CREATE INDEX ON mesures_capteurs (site, time DESC);L’appel create_hypertable transforme ta table classique en hypertable. À l’extérieur, tu continues à faire des SELECT et INSERT standards. À l’intérieur, TimescaleDB partitionne automatiquement par tranches de 7 jours (paramétrable). Une requête sur les 24 dernières heures n’a besoin de scanner qu’une seule partition au lieu de toute la table, d’où des performances qui restent constantes même quand tu accumules 5 ans de données.
Ingérer des millions de points sans saturer le serveur
Pour une PME qui équipe par exemple 10 entrepôts de capteurs IoT (température, humidité, ouverture de porte) émettant chaque minute, on parle de 14 400 mesures par jour soit ~5 millions par an. C’est un volume modeste pour TimescaleDB. Voici un exemple Python d’ingestion par batch via psycopg avec execute_values qui pousse 1000 lignes en une seule requête :
import psycopg
from psycopg.rows import dict_row
from datetime import datetime, timedelta
import random
with psycopg.connect("postgresql://pme:mot-de-passe-fort@localhost/iot_pme") as conn:
with conn.cursor() as cur:
batch = []
now = datetime.utcnow()
for i in range(10000):
batch.append((
now - timedelta(seconds=i),
f"capteur-{random.randint(1, 50)}",
random.uniform(2.0, 8.0), # Température en °C (chambre froide)
"celsius",
"dakar-entrepot-1"
))
cur.executemany(
"INSERT INTO mesures_capteurs (time, capteur_id, valeur, unite, site) VALUES (%s, %s, %s, %s, %s)",
batch
)
conn.commit()Sur un CX22, ce script ingère 10 000 mesures en moins de 2 secondes. Pour des volumes plus importants (>100 000 lignes par batch), utilise COPY qui est encore 10× plus rapide.
Continuous aggregates : la vraie magie
Imaginons que tu veuilles afficher dans Grafana la température moyenne par heure pour chaque entrepôt sur les 30 derniers jours. Naïvement, c’est une requête SELECT AVG(valeur) FROM mesures_capteurs WHERE ... GROUP BY date_trunc('hour', time), soit ~720 buckets × 50 capteurs = 36 000 agrégations à recalculer à chaque rafraîchissement du dashboard. Sur un CX22, ça prend 3 à 5 secondes par utilisateur.
TimescaleDB résout ça avec les continuous aggregates : une vue matérialisée qui se met à jour automatiquement en arrière-plan dès que de nouvelles données arrivent. Le coût de la requête tombe à quelques millisecondes :
CREATE MATERIALIZED VIEW mesures_horaires
WITH (timescaledb.continuous) AS
SELECT
time_bucket('1 hour', time) AS heure,
site,
capteur_id,
AVG(valeur) AS moyenne,
MIN(valeur) AS minimum,
MAX(valeur) AS maximum,
COUNT(*) AS nb_mesures
FROM mesures_capteurs
GROUP BY heure, site, capteur_id;
-- Activer le rafraîchissement automatique toutes les 5 minutes
SELECT add_continuous_aggregate_policy('mesures_horaires',
start_offset => INTERVAL '1 day',
end_offset => INTERVAL '1 hour',
schedule_interval => INTERVAL '5 minutes');Maintenant ton dashboard Grafana qui interroge mesures_horaires répond en moins de 100 ms même avec 5 ans d’historique. C’est cette caractéristique qui justifie à elle seule le choix de TimescaleDB pour tout projet IoT sérieux.
Politique de rétention et compression
Les données IoT s’accumulent vite. Pour rester maîtrisé, TimescaleDB offre deux mécanismes complémentaires : la rétention (suppression des données trop anciennes) et la compression (réduction du volume sans perdre les données).
-- Compression des données vieilles de plus de 7 jours
ALTER TABLE mesures_capteurs SET (
timescaledb.compress,
timescaledb.compress_segmentby = 'site,capteur_id',
timescaledb.compress_orderby = 'time DESC'
);
SELECT add_compression_policy('mesures_capteurs', INTERVAL '7 days');
-- Suppression des données vieilles de plus de 2 ans
SELECT add_retention_policy('mesures_capteurs', INTERVAL '2 years');La compression atteint typiquement un ratio de 10:1 à 20:1 sur des données IoT structurées. Tes 5 millions de mesures par an passent de ~500 Mo à ~30 Mo. Sur le SSD 40 Go d’un CX22, tu peux confortablement stocker 50 ans d’historique compressé.
Visualisation Grafana
Grafana s’intègre nativement à PostgreSQL via le plugin TimescaleDB officiel. Dans Grafana 11+, ajoute une datasource « PostgreSQL » pointant sur ton CX22, et active l’option « TimescaleDB ». Tu peux ensuite construire des dashboards très lisibles avec des panneaux Time series, Heatmaps, ou Stat. Pour les équipes opérationnelles à Dakar, Abidjan ou Ouagadougou, Grafana en français (depuis la 9.0) consultable depuis un téléphone Android via 4G fait des merveilles.
Adaptation au contexte ouest-africain
L’IoT s’industrialise rapidement en Afrique de l’Ouest, mais avec des contraintes spécifiques que TimescaleDB gère particulièrement bien. Premièrement, la connectivité intermittente : un capteur dans un entrepôt à Conakry peut perdre la 3G plusieurs heures par jour. Ton ingestion doit gérer les buffers locaux et les pousses différées. TimescaleDB accepte sans broncher des INSERT avec time dans le passé, contrairement à certains TSDB stricts.
Deuxièmement, la souveraineté des données : les transactions Wave Money, Orange Money, MTN Mobile Money sont stratégiques. Les héberger sur Hetzner Falkenstein ou Helsinki via TimescaleDB self-hosted, c’est garder ton flux dans une juridiction RGPD-compatible sans dépendre d’InfluxDB Cloud (USA) ou d’AWS Timestream (USA). Troisièmement, le coût marginal d’un capteur supplémentaire : ajouter le 51e capteur à ton hypertable n’augmente pas tes coûts (pas de licence par device), contrairement à des solutions SaaS facturées par capteur ou par millions de points/mois.
Enfin, la conformité aux lois locales sur la conservation des données. La loi sénégalaise impose la conservation des journaux d’accès pendant 12 mois. La compression et la rétention TimescaleDB rendent cette obligation indolore en termes de coûts.
Trois cas d’usage concrets
- Chaîne de boulangeries à Abidjan (12 boutiques) — capteurs de température dans les chambres froides, alertes Slack quand la température dépasse 8 °C pendant plus de 5 minutes. Économie estimée : 4 millions F CFA/an de marchandise sauvée. Stack : Raspberry Pi par boutique → MQTT → TimescaleDB sur CX22 → Grafana avec alerting.
- Opérateur de microfinance au Burkina (200 000 transactions/jour) — ingestion temps réel des transactions, dashboard de suivi par agence, détection d’anomalies (pic de retraits suspect). TimescaleDB CX42 + Continuous Aggregates par 5 minutes. ROI : détection d’une fraude de 8,5 millions F CFA en septembre 2025.
- Plateforme logistique à Bamako — tracking GPS de 80 camions toutes les 30 secondes, géofencing avec PostGIS. TimescaleDB + PostGIS sur le même VPS, requêtes spatiales temporelles unifiées. Coût total infra : 5 200 F CFA/mois.
Erreurs fréquentes à éviter
- Choisir un chunk_time_interval inapproprié — par défaut 7 jours, mais si tu ingères 100 Go par jour, passe à 1 jour. Si tu ingères 100 Mo par jour, passe à 30 jours. Cible : ~25 % de la RAM par chunk actif.
- Oublier les index secondaires — pour les requêtes filtrées par
capteur_idousite, sans index ces requêtes deviennent lentes après quelques millions de lignes. - Utiliser SERIAL au lieu de TIMESTAMPTZ comme clé temporelle — TimescaleDB partitionne sur le timestamp, pas sur un ID auto-incrémenté. Tu perds tous les bénéfices.
- Activer la compression sans tester — la compression rend les UPDATE et DELETE plus coûteux. Vérifie ton pattern d’accès avant de l’activer.
- Backup négligé — utilise
pg_dumpavec compression ZSTD vers Hetzner Object Storage en cron quotidien.
Checklist post-déploiement
- ✅ TimescaleDB installé, version vérifiée par
SELECT extversion FROM pg_extension WHERE extname='timescaledb' - ✅
timescaledb-tuneexécuté - ✅ Au moins une hypertable créée avec index secondaires
- ✅ Test d’ingestion 100 000 lignes < 5 secondes
- ✅ Au moins un continuous aggregate avec policy active
- ✅ Politique de rétention configurée
- ✅ Politique de compression configurée et testée
- ✅ Backup quotidien
pg_dumpautomatisé - ✅ Grafana datasource PostgreSQL avec option TimescaleDB activée
- ✅ Au moins un dashboard partagé avec l’équipe métier
FAQ
TimescaleDB vs InfluxDB : que choisir en 2026 ?
TimescaleDB pour la flexibilité (SQL standard, joins, écosystème PostgreSQL) et la souveraineté (totalement open-source). InfluxDB pour les workloads très spécialisés à très haut débit (>1 million de points/seconde) où sa colonne dédiée écrase tout. Pour 95 % des PME, TimescaleDB est le choix raisonnable.
Puis-je migrer d’InfluxDB vers TimescaleDB ?
Oui. L’outil outflux officiel automatise la migration. Compte 1 jour de travail pour une base InfluxDB de 10 Go.
Quelle est la consommation RAM ?
TimescaleDB ajoute ~5 % à PostgreSQL. Sur un CX22 (4 Go), tu peux gérer une hypertable de 100 millions de lignes sans souci, à condition d’avoir des index pertinents.
TimescaleDB Cloud ou self-hosted ?
Self-hosted sur Hetzner pour les PME francophones d’Afrique de l’Ouest : moins cher, données dans une juridiction maîtrisée. Cloud uniquement si tu n’as aucune compétence ops et que ton budget supporte 99 USD+/mois.
Pour aller plus loin
- 📖 Guide général Bases de données modernes 2026
- 🦆 DuckDB pour l’analytique Python sur VPS Hetzner
- 🤖 RAG OHADA avec pgvector et embeddings open source
- 📊 Monitoring réseau PME avec Grafana et Prometheus
- 🌍 Documentation officielle TimescaleDB
Besoin d’aide pour structurer ton IoT ?
Tu déploies des capteurs, tu collectes des transactions Wave/Orange Money, ou tu construis un dashboard temps réel ? ITSkillsCenter propose un audit gratuit de 30 minutes pour cadrer ton projet TimescaleDB. Contacte-nous via WhatsApp +221 78 226 83 77 ou demande directement ton audit gratuit en ligne.
[ITS] ITSkillsCenter — formations IT et conseil pour PME d’Afrique de l’Ouest. Dakar · Abidjan · Ouagadougou · Bamako · Conakry. Tous nos contenus sont audités selon notre charte éditoriale Ahl-Sunna.