Le problème
Sur les marchés d'actifs numériques, une part importante des mouvements de prix brutaux est précédée d'un événement d'offre observable : déblocage programmé de jetons, destruction, transfert massif vers une place de marché. L'information est publique et inscrite sur les chaînes — mais elle est éparpillée entre plusieurs réseaux, plusieurs fournisseurs de données, et arrive rarement au bon moment.
Ce projet consolide ces signaux en un flux unique, les note selon leur importance, et alerte. C'est délibérément un outil d'observation : la partie exécution existe dans le code mais reste désactivée par défaut, derrière plusieurs verrous.
Ce que j'ai construit
Surveillance multi-chaînes
un réseau à haut débit et quatre réseaux compatibles EVM suivis en parallèle.
Agrégation multi-sources
plusieurs fournisseurs de calendriers de déblocage et de données de marché, avec repli automatique de l'un sur l'autre.
Moteur de notation
pondération des événements selon leur ampleur relative et leur contexte, pour éliminer le bruit.
Alertes instantanées
notifications formatées poussées par messagerie.
Découverte automatique
balayage périodique des actifs les plus capitalisés pour étendre la couverture sans configuration manuelle.
Backtesting
rejeu historique des signaux pour mesurer leur pertinence avant de leur faire confiance.
Tableau de bord
interface de consultation des événements et de leur notation.
Architecture & choix techniques
L'ensemble est écrit en Python asynchrone, parce que la charge est presque entièrement composée d'attentes réseau : interroger des nœuds de chaînes et des API externes en parallèle est exactement le cas d'usage où l'asynchrone change l'échelle atteignable.
Chaque famille de signaux est traitée par un worker indépendant — déblocages, valorisation, événements on-chain, actualité — orchestrés par un planificateur. Une source qui tombe ne fait pas tomber le système : elle dégrade une dimension du score, et c'est visible.
Les fournisseurs externes sont derrière une interface commune avec relances et repli. Dans ce domaine, les API changent, imposent des quotas ou disparaissent : aucune source ne doit être structurante.
La partie exécution est protégée par un interrupteur à trois positions — désactivé, simulation, réel — avec des limites de risque strictes et un environnement de test par défaut. Le comportement par défaut d'un outil financier automatisé doit être de ne rien faire.
Les défis techniques
Des données contradictoires. Deux fournisseurs annoncent rarement le même calendrier de déblocage : il faut arbitrer, dater et conserver l'origine de chaque information.
Le bruit. Un système d'alerte qui alerte trop n'est plus lu — la notation existe autant pour filtrer que pour hiérarchiser.
Les quotas d'API. Cache en mémoire à durée de vie, relances exponentielles et regroupement des appels pour rester dans les limites des fournisseurs.
La mesure de la pertinence. Le backtesting sert précisément à éviter de croire un signal sur son apparente évidence.
La discipline de sécurité. Séparer strictement observation et exécution, et faire de l'inaction le comportement par défaut.