Le coût d'un petit bug dans le trading automatisé

Une réalité inconfortable des systèmes automatisés, c'est que la taille d'un bug et la taille de ses conséquences ne sont pas toujours liées.

Une condition peut être légèrement trop permissive. Un état peut être mis à jour au mauvais moment. Une réponse externe peut être interprétée autrement que prévu.

Dans un logiciel classique, un petit bug peut créer une petite gêne. Dans le trading automatisé, la même erreur peut continuer à influencer les décisions pendant que personne ne regarde.

C'est ce qui rend le problème différent.

L'automatisation amplifie la répétition

Les erreurs manuelles sont naturellement limitées par l'attention humaine.

Le logiciel n'a pas cette hésitation. Si la logique lui dit de répéter le même comportement mille fois, il le fera exactement. Le bon comportement se répète sans effort, mais le mauvais aussi.

Les bugs dangereux ne sont donc pas toujours des crashs spectaculaires.

Parfois, ce sont des opérations valides exécutées sous une mauvaise hypothèse. Le système ne sait pas que l'hypothèse est fausse. Il sait seulement que la condition est remplie.

Les petites erreurs deviennent opérationnelles

Un petit bug dans un système de trading reste rarement isolé longtemps.

Il peut toucher la taille des ordres, le suivi des positions, le solde disponible, le timing d'exécution ou la logique de récupération. Aucun de ces problèmes n'a besoin d'avoir l'air dramatique au départ. Le système peut continuer à tourner, les logs peuvent continuer à défiler et le dashboard peut encore sembler normal.

C'est précisément pour cela que ces problèmes comptent.

Les bugs les plus coûteux ne sont pas toujours ceux qui arrêtent tout immédiatement. Parfois, le pire scénario est un système qui continue de fonctionner tout en s'éloignant lentement de la réalité.

Les garde-fous ne sont pas optionnels

Certaines des améliorations les plus précieuses que j'ai apportées à Oblivion auraient l'air totalement inintéressantes dans une annonce produit.

Une meilleure validation. Des transitions d'état plus claires. Une gestion plus défensive des réponses inattendues. Des vérifications supplémentaires avant de poursuivre une opération.

Aucune de ces choses ne produit de capture d'écran impressionnante, mais chacune supprime un chemin par lequel une petite incohérence pourrait devenir un problème plus large.

Avec le temps, j'ai appris à respecter ce travail davantage que les nouvelles fonctionnalités. Il n'étend pas ce que le système peut faire. Il réduit le nombre de façons dont il peut mal se comporter.

L'emplacement compte plus que le bug

Construire un logiciel de trading automatisé m'a appris à ne plus juger les bugs uniquement par leur complexité technique.

Ce qui compte, c'est l'endroit où le bug se trouve, la fréquence à laquelle ce chemin s'exécute et ce qui arrive quand son hypothèse sous-jacente est fausse.

Un petit problème dans un écran rarement utilisé peut être agaçant. Un petit problème dans l'allocation du capital, l'exécution des ordres ou la récupération d'état est différent. Le contexte autour du bug change le risque.

Le système continuera à faire ce qu'on lui a demandé de faire. La responsabilité consiste à s'assurer qu'on lui a demandé la bonne chose.

Avec le recul

C'est l'une des raisons pour lesquelles je suis devenu plus prudent à mesure qu'Oblivion mûrissait.

Au début, le progrès ressemblait à l'ajout de nouvelles capacités. Plus tard, le progrès a souvent consisté à retirer de l'ambiguïté, à renforcer les vérifications et à rendre les échecs plus faciles à détecter.

Dans le trading automatisé, la fiabilité ne vient pas du fait de supposer que les petits bugs resteront petits.

Elle vient du fait de concevoir le système comme si les petits bugs méritaient de l'attention avant d'avoir l'occasion de devenir coûteux.