Deux dépôts GitHub suffiraient à transformer un ordinateur ordinaire en station de recherche digne d’un terminal Bloomberg : j’y crois à moitié. Avec REA et Kronos, auxquels on ajoute Claude Code comme liant, on peut assembler quelque chose qui fonctionne vraiment : d’un côté, récupérer les cours, calculer des facteurs et effectuer des backtests ; de l’autre, demander au modèle de lire les annonces, de rédiger des rapports quotidiens et de générer des hypothèses de trading. Le résultat en a l’air. Mais dans un assemblage de ce genre, le plus difficile n’est jamais le code : ce sont les sources de données et la latence. On peut compléter le code grâce aux dépôts open source et à Claude Code, mais les données, il faut les intégrer une par une. Les API gratuites de données de marché imposent souvent des limites de fréquence, par exemple quelques requêtes par minute seulement, et les données boursières peuvent aussi avoir 15 minutes de retard. Pour obtenir le carnet d’ordres Level-2 en temps réel et les transactions détaillées, il faut compter entre quelques centaines et quelques milliers de dollars par mois. Les données alternatives, l’analyse des actualités et des annonces, ainsi que la synchronisation des fuseaux horaires sont autant de pièges invisibles. J’ai vu un cas d’assemblage très classique : une interface gratuite récupérait les données journalières pour les backtests, et la courbe annualisée était superbe. Mais dès le passage au trading simulé, on s’est aperçu que le signal avait plusieurs dizaines de secondes de retard sur les transactions réelles, et que le slippage absorbait plus de la moitié des gains. Alors, « transformer un ordinateur ordinaire en terminal Bloomberg », ça fonctionne pour le processus de recherche, mais en matière de qualité des données et de latence d’exécution, on est encore loin d’un vrai terminal.

Je suis les guildes de jeux blockchain depuis un bon moment. Les modèles économiques on-chain auront beau être sophistiqués, ils dépendent au bout du compte de la fidélisation des vrais joueurs. Même les meilleurs outils ne peuvent rien pour un jeu auquel personne ne joue. Certains projets affichent par exemple une TVL et un volume de transactions NFT impressionnants, mais ne comptent que quelques centaines d’utilisateurs actifs quotidiens. La production issue du play-to-earn dépasse durablement la consommation ; dès que le nombre de nouveaux joueurs diminue, le cours du jeton et les revenus des guildes s’effondrent ensemble. À l’inverse, pour les jeux qui fidélisent leurs joueurs, même des outils rudimentaires suffisent aux guildes pour se développer progressivement grâce à une production stable et à l’activité des joueurs. Les outils peuvent rendre plus efficaces la collecte de données, le calcul des revenus et la surveillance des adresses, mais ils ne peuvent pas créer le plaisir de jouer ni fidéliser les joueurs à partir de rien. Je garde cette hypothèse sous le coude et je reviendrai la vérifier demain : faire tourner pendant une semaine la même pile REA + Kronos + Claude Code, consigner le taux d’échec des sources de données, la latence de bout en bout et les écarts entre les signaux et le jugement humain, puis comparer ces résultats à la rétention des jeux des guildes au jour suivant et à 7 jours, ainsi qu’aux dépenses réelles. On verra alors si les outils ont vraiment complété la station de recherche, ou si le plafond reste déterminé par les sources de données et la fidélisation.