Un ticker Bitcoin low-code construit avec QuestDB et n8n.io : Guide complet et alternatives

Eliott Ardisson

Founder & CEO - Basalt Studio

Feb 3, 2026

Updated May 16, 2026

insights

Comment construire un ticker Bitcoin automatisé avec n8n et QuestDB : architecture, étapes d'implémentation, bonnes pratiques et pièges à éviter.

ai agents

automation

programmatic

Points clés

Un ticker Bitcoin low-code repose sur trois blocs principaux : un orchestrateur de workflow (n8n), une source de données via API publique, et une base de données de séries temporelles (QuestDB).
L’approche self-hosted donne un contrôle total sur vos données historiques, sans dépendance à un fournisseur SaaS qui peut changer ses tarifs ou fermer son service.
QuestDB est conçu nativement pour les données temporelles à haute fréquence — sa syntaxe SQL standard réduit la courbe d’apprentissage par rapport à d’autres bases NoSQL spécialisées.
La gestion des erreurs et les APIs de fallback sont les deux points les plus sous-estimés dans ce type de projet — les APIs crypto peuvent être instables en période de forte volatilité.
Ce projet pilote est un bon point d’entrée pour comprendre les pipelines de données automatisés avant de les appliquer à des cas d’usage métier plus complexes.

Ce que fait concrètement un ticker Bitcoin low-code

Un ticker Bitcoin low-code est un pipeline de données automatisé qui interroge périodiquement une API publique de prix, traite la réponse, et insère les données dans une base de données de séries temporelles — le tout sans écrire une application backend complète.

L’intérêt de cette approche n’est pas purement technique. Pour une PME qui veut construire un outil de suivi interne, ou pour un développeur solo qui veut prototyper rapidement, l’approche low-code réduit le temps entre l’idée et le premier jeu de données fonctionnel. Là où un développement traditionnel nécessiterait de configurer un serveur, écrire un client HTTP, gérer les erreurs, implémenter le stockage et prévoir la supervision, une stack n8n + QuestDB permet d’atteindre un résultat comparable en quelques heures.

Cela ne signifie pas que l’approche est sans contraintes. Le débogage d’un workflow visuel a ses propres subtilités, et QuestDB demande une configuration initiale soignée. Mais pour un projet de surveillance de données financières à cette échelle, c’est une des voies les plus directes.

Architecture du système en trois blocs

Avant de toucher à l’interface, il est utile de comprendre la structure logique du système. Elle tient en trois éléments.

Le déclencheur temporel : n8n exécute le workflow selon une fréquence définie (toutes les minutes, toutes les heures, etc.) via un nœud Cron. C’est lui qui donne le rythme à l’ensemble du pipeline.

Le collecteur et processeur de données : un nœud HTTP Request interroge une API publique de prix Bitcoin (CoinGecko, Binance API, ou une alternative). Un nœud Set extrait ensuite les champs utiles — prix actuel, volume, variation sur 24h, horodatage — et les convertit aux types appropriés.

Le stockage : QuestDB reçoit les données et les insère dans une table de séries temporelles. Chaque enregistrement est horodaté à la microseconde, ce qui permet des requêtes d’agrégation temporelle très efficaces.

Ces trois blocs sont indépendants. Si vous voulez changer d’API source ou migrer vers une autre base de données, vous modifiez un seul maillon sans toucher aux autres. C’est la valeur réelle de l’architecture modulaire dans ce contexte.

Pourquoi n8n pour l’orchestration

n8n est un outil d’automatisation open-source avec une interface visuelle de type workflow. Il est auto-hébergeable, ce qui le distingue des outils SaaS d’automatisation dont les coûts peuvent devenir significatifs à haute fréquence d’exécution.

Pour ce type de projet, ses atouts sont concrets :

Visibilité sur les données en transit : chaque nœud affiche ce qu’il reçoit et ce qu’il transmet, ce qui rend le débogage beaucoup plus direct qu’un script opaque.
Gestion des erreurs native : vous pouvez configurer des branches d’erreur, des retries automatiques et des notifications sans code supplémentaire.
Extensions sans friction : ajouter une alerte Slack ou un email en cas d’anomalie de prix prend quelques minutes une fois le workflow de base en place.

Un point à garder à l’esprit : n8n en mode cloud a une structure tarifaire basée sur le nombre d’exécutions. Pour un ticker qui tourne toutes les minutes, cela représente environ 44 000 exécutions par mois. Il est préférable de l’auto-héberger via Docker pour ce cas d’usage précis.

Déploiement avec Docker : les étapes essentielles

Prérequis

Docker doit être installé sur votre machine ou serveur. Une configuration minimale de 4 Go de RAM suffit pour un usage mono-utilisateur ; prévoyez 8 Go si vous envisagez de stocker plusieurs années de données ou d’ajouter d’autres actifs.

Lancer n8n

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -v ~/.n8n:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

L’interface est accessible sur http://localhost:5678. Le volume monté dans ~/.n8n permet de persister vos workflows entre les redémarrages du conteneur.

Lancer QuestDB

docker run -p 9000:9000 -p 9009:9009 -p 8812:8812 \
  --name questdb \
  questdb/questdb

Trois ports sont exposés : 9000 pour l’interface web, 9009 pour le protocole InfluxDB Line (utile pour les insertions haute fréquence), et 8812 pour la compatibilité PostgreSQL wire protocol.

Créer la table de réception

Depuis l’interface web de QuestDB (port 9000), créez la table avec une requête SQL simple :

CREATE TABLE btc_prices (
  ts TIMESTAMP,
  price DOUBLE,
  volume DOUBLE,
  change_24h DOUBLE
) TIMESTAMP(ts) PARTITION BY MONTH;

Le partitionnement mensuel accélère les requêtes qui portent sur des plages temporelles limitées, ce qui est le cas de la plupart des analyses techniques.

Configurer le workflow n8n

Une fois les deux services actifs, le workflow dans n8n suit cette séquence :

Nœud Cron : planifié à */1 * * * * pour une exécution par minute.
Nœud HTTP Request : GET vers l’endpoint de prix de votre API choisie. Pour CoinGecko, l’endpoint public /simple/price ne nécessite pas d’authentification pour un usage modéré.
Nœud Set : extraction des champs prix, volume, variation_24h et génération d’un timestamp ISO.
Nœud QuestDB : insertion via le protocole PostgreSQL ou InfluxDB Line selon votre préférence.

QuestDB propose un nœud communautaire pour n8n, mais la connexion via un nœud PostgreSQL standard fonctionne également bien en utilisant le port 8812.

Un template JSON est disponible dans la documentation officielle de QuestDB pour importer directement ce workflow, ce qui évite de reconfigurer chaque nœud manuellement.

Pourquoi QuestDB plutôt qu’une base généraliste

La question se pose légitimement : pourquoi ne pas simplement utiliser PostgreSQL ou SQLite ?

QuestDB est conçu autour d’un modèle de stockage orienté colonnes, optimisé pour les insertions et les agrégations temporelles à haute fréquence. Concrètement, les requêtes du type “prix moyen toutes les 15 minutes sur les 30 derniers jours” ou “plus grand delta de prix en une heure” s’exécutent nettement plus vite que sur une base relationnelle classique sur des volumes comparables.

Sa syntaxe SQL étendue inclut des fonctions temporelles natives comme SAMPLE BY pour les agrégations par périodes, ce qui évite d’écrire des GROUP BY complexes. Pour quelqu’un qui connaît déjà SQL, la prise en main est courte.

Par rapport à InfluxDB, QuestDB est plus proche du SQL standard, ce qui le rend plus accessible à une équipe qui n’est pas spécialisée en bases de données de séries temporelles. TimescaleDB est une alternative sérieuse si votre organisation utilise déjà PostgreSQL de manière intensive, mais elle ajoute une couche de complexité à l’administration.

Gestion des erreurs : le point le plus souvent négligé

Les APIs crypto publiques ne sont pas des services de niveau entreprise. En période de forte volatilité, elles peuvent ralentir, retourner des erreurs 429 (rate limit) ou des réponses malformées. Un ticker qui tombe silencieusement en panne la nuit et ne remonte les données que le matin est peu utile.

Voici les mécanismes à mettre en place dès le départ :

Retry automatique avec backoff : configurer n8n pour retenter l’exécution 2 ou 3 fois avec un délai croissant (quelques secondes entre chaque tentative) avant de lever une erreur.

API de fallback : configurer une branche conditionnelle dans le workflow qui bascule vers une deuxième source (par exemple Binance si CoinGecko ne répond pas). Cette redondance évite les trous dans vos données historiques.

Validation des données : un filtre sur les valeurs aberrantes — par exemple, rejeter tout prix qui représente une variation instantanée de plus de 30% par rapport à la dernière valeur stockée — protège contre les réponses corrompues ou les erreurs d’API.

Alertes sur échecs répétés : une notification sur un canal Slack ou par email après trois échecs consécutifs suffit pour intervenir rapidement sans générer de bruit inutile.

Dans notre travail avec des PME qui construisent des pipelines de données automatisés, chez Basalt Studio, ce sont ces mécanismes de résilience qui font la différence entre un système qui tient en production et un prototype qui fonctionne uniquement en démo.

Comparatif des approches pour collecter des données de prix

Approche	Coût estimé / mois	Contrôle des données	Complexité initiale	Maintenance
n8n self-hosted + QuestDB	Infrastructure serveur uniquement	Total	Modérée	Faible à moyenne
Outils d’automatisation SaaS	Variable selon volume d’exécutions	Partiel	Faible	Très faible
APIs premium de données financières	Souvent élevé pour du temps réel	Aucun	Très faible	Nulle
Développement backend sur mesure	Coût de développement initial significatif	Total	Élevée	Élevée

Le principal arbitrage est entre contrôle et simplicité opérationnelle. Pour une organisation qui veut construire une base de données historique propriétaire sur le long terme, le self-hosting a du sens. Pour un usage ponctuel ou un projet de test, une API premium ou un outil SaaS peut suffire.

Étendre le système au-delà de Bitcoin

Une fois le ticker Bitcoin fonctionnel, l’architecture se transpose facilement à d’autres actifs. Il suffit de dupliquer le workflow et d’ajuster l’endpoint API pour Ethereum, des indices boursiers, ou des taux de change.

À terme, le même pipeline peut alimenter des dashboards d’analyse technique, des alertes de seuil de prix, ou des exports vers des outils de reporting. Les requêtes SQL de QuestDB permettent de calculer des moyennes mobiles, des bandes de Bollinger ou d’autres indicateurs directement en base, sans couche de traitement supplémentaire.

La question de la conformité réglementaire mérite également d’être posée tôt. Selon l’usage final des données (usage interne, publication, décisions d’investissement), des règles de traçabilité et de conservation des données peuvent s’appliquer, notamment dans le cadre de MiFID II en Europe.

Pour aller plus loin

Un ticker Bitcoin low-code est un projet concret pour apprendre les bases des pipelines de données automatisés. Les mêmes principes — déclencheur, collecte via API, transformation, stockage structuré — se retrouvent dans des dizaines de cas d’usage métier : collecte de leads, synchronisation de CRM, import de données comptables, surveillance de KPIs opérationnels.

Si vous souhaitez explorer comment ce type d’automatisation peut s’appliquer à votre activité, vous pouvez réserver un appel stratégie avec l’équipe Basalt Studio pour en discuter : https://cal.com/eliott-ardisson-kzq7zs/ai-strategy-call