La crypto ne dort jamais : pourquoi un marché 24/7 exige une infrastructure 24/7

La crypto ne dort jamais : pourquoi un marché 24/7 exige une infrastructure 24/7

Je me souviens exactement du moment où j'ai compris à quel point le trading permanent est fragile. Il était 2 h 47, un mardi. Je surveillais le bot d'arbitrage d'un client quand le flux WebSocket de l'exchange est devenu muet. Pas un message de crash, pas un avertissement de rate-limit. Juste le silence. Le bot a continué à placer des ordres sur la base de prix périmés pendant onze minutes avant que je m'en rende compte. À ce moment-là, les dégâts étaient faits.

C'est ça, le problème des marchés 24/7 : il n'y a pas de cloche de fermeture pour cacher les pannes. Quand les marchés traditionnels ferment, les problèmes sont reportés au lendemain. En crypto, chaque seconde d'indisponibilité est une seconde où quelqu'un d'autre trade — contre toi, sans toi, ou par-dessus tes ordres.

La cloche de fermeture, c'est un hôpital pour les systèmes cassés

Les marchés financiers traditionnels ont quelque chose que la crypto n'a pas : un moment où ça ferme. Le NASDAQ ne s'arrête pas à 16 h, heure de New York, pour le plaisir. Cette cloche donne à tout le monde un moment pour réconcilier les comptes, corriger les bugs, patcher les failles et repartir sur une base saine. C'est une fenêtre de maintenance nocturne qui soutient tranquillement la stabilité des marchés actions depuis des décennies.

La crypto, elle, ne s'arrête jamais. Bitcoin ne prend pas de pause déjeuner. Ethereum ne passe pas à l'heure d'hiver. Quand ma précédente startup a construit un bot de market-making, notre première question n'était pas « quelle est notre stratégie ? » mais « qu'est-ce qui se passe quand AWS us-east-1 tombe à 3 h du matin ? »

La plupart des équipes n'ont pas de bonne réponse à ça.

Ce qui se passe vraiment quand l'infrastructure lâche

Laisse-moi te donner trois scénarios réalistes. Aucun n'est hypothétique.

Scénario 1 : la trader de Tokyo et l'exchange de Francfort

Yuki gère un portefeuille crypto modeste à Tokyo. Elle travaille, donc ses sessions de trading sérieuses se passent entre 1 h et 4 h du matin, heure locale — quand les marchés américains sont actifs et que la volatilité explose. Une nuit, son exchange préféré affiche « 503 Service Unavailable » pendant près de quarante minutes en plein événement de liquidation massive.

Yuki ne peut pas fermer une position qui saigne. Elle regarde sa marge se faire dévorer par les funding rates pendant que la page de statut de l'exchange affiche « All systems operational » — une page manifestement consultée par des humains uniquement pendant les heures de bureau.

Résultat ? Yuki ne perd pas seulement de l'argent. Elle perd confiance. Elle déplace ses actifs ailleurs et raconte l'incident à son groupe de trading de quatre personnes. La panne d'infrastructure de l'exchange ne leur a pas coûté un utilisateur ; elle leur a coûté tout un réseau.

Scénario 2 : le flash crash et l'oracle lent

Un protocole de prêt décentralisé a un moteur de liquidation qui s'appuie sur des oracles de prix mis à jour toutes les 15 minutes. Pendant un flash crash, l'actif sous-jacent chute de 23 % en quatre minutes. L'oracle — qui tourne sur une infrastructure sans redondance suffisante — prend sept minutes de retard.

Quand l'oracle rattrape son retard, des dizaines de positions sous-collatéralisées ont déjà glissé entre les mailles du filet. Le tableau de bord des risques du protocole semble sain parce qu'il lit des données périmées. Résultat : le protocole avale 3 millions de dollars de bad debt parce que son infrastructure « temps réel » n'était pas vraiment temps réel.

Le pire ? Un simple changement d'architecture — faire tourner des nœuds oracle redondants dans plusieurs régions et agréger les prix via une médiane — aurait évité tout le désastre.

Scénario 3 : le rate-limit API qui a tué un bot

Sophia dirige une petite firme de trading propriétaire. Son équipe a un beau déploiement de bots orchestré avec Kubernetes qui auto-scaling parfaitement en conditions normales. Pendant un pic de volatilité brutal à 2 h du matin, la demande sur l'API publique de l'exchange triple. L'infrastructure de l'exchange — dimensionnée pour la charge moyenne, pas pour les pics — se met à rate-limiter agressivement.

Le bot de Sophia se fait étrangler en plein milieu de sa stratégie. Il ne peut ni annuler les ordres, ni ajuster les offres, ni faire quoi que ce soit, à part attendre. Quand le rate-limit se lève, le marché a bougé contre ses positions, et le code de « sécurité » du bot exécute une vente panique au pire moment possible.

Alors, à quoi ressemble une vraie infrastructure 24/7 ?

Quand je parle à des fondateurs et des ingénieurs qui construisent pour la crypto, ils ont souvent les bons instincts mais la mauvaise échelle. Ils pensent que quelques serveurs redondants et un dashboard de monitoring suffisent. Non.

La redondance géographique n'est pas négociable

Si toute ton infrastructure vit dans une seule région cloud, tu ne fais pas tourner de l'infrastructure 24/7. Tu fais tourner de l'infrastructure « parfois », avec de jolies stats d'uptime.

Tes clusters Kubernetes devraient être répartis sur au moins deux, idéalement trois, régions géographiques. Les fournisseurs cloud ont facilité les choses — AWS Global Accelerator et le load balancing multi-régions de GCP aident — mais la responsabilité reste sur tes épaules : il faut concevoir pour la panne régionale. La plupart des équipes conçoivent pour la panne d'un service, pas pour la panne d'une région. C'est très différent.

Ton health check devrait tester ton pire jour

La plupart des systèmes de monitoring sont aussi efficaces qu'un détecteur de fumée sans piles. Ils t'alertent quand quelque chose est déjà tombé, et à ce moment-là le marché a déjà bougé.

Ce que je recommande, c'est un truc légèrement obsessionnel : des systèmes de failover pré-provisionnés et testés activement chaque semaine. Ne te contente pas d'avoir un backup — bascule réellement dessus. Envoie-lui de la merde. Tue ton service principal en production et regarde ce qui se passe. C'est flippant, mais c'est moins cher que d'apprendre les faiblesses de ton infrastructure pendant un événement de marché.

Le chaos engineering est ton ami, pas un mot à la mode

Netflix a popularisé le chaos engineering avec Chaos Monkey. Pour les systèmes de trading, l'équivalent est bien plus agressif. Ton système devrait tolérer, sans intervention humaine :
- Une région cloud entière qui s'éteint
- Des réplicas de base de données qui laguent de plusieurs minutes
- L'exchange dont tu dépends qui rate-limite toutes tes clés
- Ton système de gestion de secrets qui est compromis

Fais des game days. Casse des trucs exprès. Si ton équipe ne peut pas gérer une panne injectée un jeudi après-midi, elle ne pourra certainement pas gérer la vraie à 2 h du matin.

La conscience des rate-limits est un avantage compétitif

Quand tu construis pour des marchés 24/7, l'exchange n'est pas ton partenaire — c'est un adversaire potentiel. La plupart des exchanges limitent tes requêtes API quand leur propre infrastructure est sous pression. Si ton système n'a pas de backoff intégré, de file d'attente et de dégradation gracieuse, tu seras le premier coupé au moment où ça compte le plus.

Construis comme si l'exchange était toujours à un incident près de te throttler. Parce que c'est le cas.

Le côté humain : on ne fait pas tourner du 24/7 avec une équipe de 9 à 5

Parlons de la partie que personne ne veut aborder. Même avec une automatisation parfaite, quelqu'un doit être réveillé et responsable. Le modèle « on réveille les fondateurs » s'effondre après le troisième incident à 3 h du matin.

Mon opinion est ferme : si tu fais tourner de l'infrastructure de trading, il te faut un vrai système d'astreinte avec des chemins d'escalade. Pas un « on surveille Slack tous ensemble » mais une vraie astreinte structurée. Utilise des outils comme PagerDuty ou Opsgenie. Crée des runbooks pour chaque incident prévisible. Et pour l'amour du ciel, documente tes incidents — une culture du postmortem n'est pas de la bureaucratie, c'est comme ça qu'on évite de répéter les leçons douloureuses.

Le lien avec l'IA

On voit une révolution silencieuse dans la façon dont cette infrastructure fonctionne. Les agents IA deviennent la première ligne de défense pour beaucoup d'équipes. Le mode « auto » de Claude Code est maintenant activé par défaut, ce qui veut dire qu'on va voir de plus en plus d'agents autonomes gérer des tâches d'ops courantes avec un minimum de supervision humaine.

Mais voici mon avertissement : les agents autonomes valent ce que valent les garde-fous que tu construis autour d'eux. Les sandboxes Docker pour agents IA (docker.com/products/docker-sandboxes/) offrent un environnement jetable et isolé — comme ça tu peux laisser une IA enquêter sur un incident ou tester un script de failover sans t'inquiéter qu'elle vienne fouiner dans ta production. Utilise ça. Sandboxe toujours tes outils autonomes.

De même, quand tu écris des scripts pour ton infrastructure, souviens-toi que le durcissement de GitHub Actions compte. Mets des permissions au minimum sur tes workflows — un script de déploiement qui a accès à plus que nécessaire, c'est une responsabilité qui n'attend qu'à se déclencher.

Actions pratiques

Si tu es en train de lire ça et que tu te dis « il faut qu'on répare notre infrastructure », commence ici :

1. **Audite ton blast radius.** Écris chaque composant de ton système. Pour chacun, demande-toi : « Si ça tombe à 3 h du matin, c'est combien de dégâts financiers ? »
2. **Tue un serveur exprès cette semaine.** Choisis un service non critique, termine son instance principale, et regarde ton équipe réagir. Chronomètre le temps de récupération.
3. **Cartographie tes dépendances.** Est-ce que tu connais chaque API externe que ton système appelle ? Leurs rate-limits ? Leur historique de pannes ? Tu devrais.
4. **Construis un squelette de runbook.** Pour tes cinq pannes les plus probables, écris la procédure de récupération maintenant. Le toi du futur, à 3 h du matin, t'en sera infiniment reconnaissant.

FAQ

Une infrastructure 24/7, c'est pas cher ?

Oui, mais moins cher que l'alternative. Faire tourner une infrastructure multi-régions peut coûter 2 à 3 fois plus cher qu'une config mono-région. Mais un seul incident significatif au mauvais moment peut effacer des années de profits. Pense-y comme à une assurance — tu ne l'achètes pas parce que tu t'attends à un incendie ; tu l'achètes parce que le coût d'un incendie est catastrophique.

Est-ce qu'une petite équipe crypto peut vraiment maintenir du 24/7 ?

Honnêtement ? Pas toute seule. Mais elle n'a pas à le faire. Utilise des services managés (AWS/GCP/Azure), repose-toi sur du Kubernetes managé (EKS, GKE, AKS), et n'essaie pas de construire ta propre base de données. Les équipes qui échouent sont celles qui essaient de tout faire elles-mêmes. Utilise une bonne infrastructure managée et garde ton temps d'ingénierie pour ce qui te différencie vraiment.

Quelle est la chose la plus importante à réussir ?

La redondance géographique pour tes services avec état. Les services sans état, comme les serveurs API, sont faciles à scaler et à déplacer. Les bases de données et les files d'attente sont le vrai défi. Si tes données ne sont pas répliquées entre les régions, tout le reste n'a aucune importance.

Comment gérer l'indisponibilité de l'API d'un exchange ?

Pars du principe que ça arrivera et construis pour la dégradation gracieuse. Mets en cache les données du carnet d'ordres mais marque-les clairement comme périmées. Implémente un backoff exponentiel. Aie un circuit breaker qui arrête le trading — ou qui passe en mode défensif — quand le flux de données dépasse un certain âge. L'objectif, c'est de perdre de l'argent lentement au lieu d'en perdre vite.

Le fond du problème

Le marché de la crypto se fiche de ton week-end. Il se fiche que tes ingénieurs soient en vacances, que ton fournisseur cloud ait eu une mauvaise journée, ou que l'équipe fasse un Zoom à minuit sans raison. Le marché est une machine qui n'avance que dans un sens.

Plus tôt tu traiteras ton infrastructure comme le système toujours allumé qu'elle doit être, moins ces appels à 3 h du matin seront douloureux. Parce que je peux te promettre une chose : si tu ne construis pas pour le 24/7, le marché trouvera la faille. Il la trouve toujours.