Étude de cas
AltitudeAltitude m’a fait venir pour améliorer son terminal de trading sur HyperEVM et développer les fonctionnalités qui manquaient. Je l’ai connecté au bot de trading et j’ai reconstruit le graphique et les données en direct pour la vitesse. Cinq mois plus tard, l’équipe avait un terminal rapide et complet à montrer aux investisseurs, avec ordres au marché et à cours limité en production.
Un terminal de trading entièrement fonctionnel
Contexte
Altitude est un terminal web pour trader des tokens sur HyperEVM. On trouve un token, on lit son graphique, et on l’achète ou le vend en un clic. Un bot de trading exécute les ordres en arrière-plan.
À mon arrivée, l’essentiel du produit était déjà construit. Mais l’expérience n’était pas encore au niveau qu’attendent les traders : graphiques et données en direct lents à charger, certains parcours peu fiables, et des fonctionnalités clés encore absentes, à commencer par le trading lui-même, puisque le panneau d’achat/vente n’était pas encore connecté au bot.
Altitude m’a fait venir pour améliorer le produit et prendre en charge les nouvelles fonctionnalités. L’objectif : un terminal de trading vraiment fonctionnel et optimisé, avec une expérience au niveau des meilleurs outils que les traders utilisent déjà.
Ce que j’ai fait
J’ai travaillé en deux phases : rendre le trading réel, puis rendre tout le terminal rapide. En parallèle, j’ai pris en charge les nouvelles fonctionnalités, puis intégré les ingénieurs arrivés à l’automne.
Altitude avait un terminal de trading à montrer et à mettre entre les mains des utilisateurs. Il a appuyé la levée de fonds.
La couche temps réel, le graphique et le store d’auth, réécrits plus légers et plus rapides.
Ordres au marché, simulation des swaps, cotations en direct et ordres à cours limité.
Phase 1
Un backend NestJS qui dialogue avec le bot de trading en gRPC avec TLS mutuel : swaps, wallets, approvals et soldes. Par-dessus, le premier vrai panneau de trading : choix du wallet, slippage, priority fee et montants prédéfinis.
Un flux partagé par token, envoyé aux navigateurs en Server-Sent Events. Il se reconnecte automatiquement et ferme les connexions que personne ne regarde. Le code client est passé d’environ 1 200 lignes à moins de 100.
Pipeline de production corrigé, dépendances de l’app et du backend figées, pages qui bloquaient le build nettoyées, et flux d’authentification simplifié.
Phase 2
Les traders n’attendent pas. Un graphique lent ou une connexion qui bloque, et ils partent. J’ai donc mis le temps là où les utilisateurs le ressentent le plus.
Graphique réécrit (environ −2 500 lignes, le store passant de 609 à 82 lignes). L’historique du pool est préchargé avant l’ouverture, les bougies plus anciennes se chargent quand on remonte, et le mobile reçoit moins de bougies et une mise en page plus légère.
Les nouvelles transactions arrivent dans le graphique, le tableau des transactions et vos positions au fil de l’eau. Vos propres trades apparaissent sur le graphique sous forme de marqueurs d’achat/vente.
Logique d’auth découpée en petits flux séparés pour Telegram et la connexion par wallet, et statut de l’utilisateur récupéré juste après la connexion pour une redirection instantanée. L’en-tête du token se charge aussi plus vite.
Chaque swap est d’abord simulé et coté par un service de quotation dédié : vous voyez ce que vous allez obtenir avant de trader.
Déclenchement à un prix ou à une market cap, avec une date d’expiration. Le statut se met à jour en direct quand l’ordre est exécuté, échoue ou expire.
J’ai aussi mis en place un process de mise en production régulier, avec des branches de hotfix et des migrations rejouables sans risque. Puis je suis devenu l’intégrateur des ingénieurs arrivés à l’automne.
Choix et arbitrages
J’ai priorisé la vue de trading, le temps de chargement et la connexion. Ce sont les moments où un utilisateur reste ou part, et ceux que les investisseurs voient en démo.
Les données de marché ne circulent que dans un sens : les Server-Sent Events étaient plus simples et plus robustes que des WebSockets côté navigateur. En contrepartie, il fallait gérer des connexions amont partagées, d’où le comptage des spectateurs et le nettoyage automatique.
Avec une levée de fonds en vue, j’ai choisi un produit qui fonctionne plutôt que des tests automatisés. C’était le bon choix à ce moment-là. C’est aussi la première chose que j’ajouterais : des tests sur l’exécution des ordres et les ordres à cours limité, plus de l’alerting.
Stack
Résultat
En cinq mois, le terminal était connecté au bot, rapide là où les traders le ressentent, et en production avec ordres au marché et à cours limité.
Parlons-en lors d’un appel gratuit de 20 minutes. Je le rends rapide, fiable et complet, puis je le fais avancer.