Vous m’avez dit que votre processus de trading paper avait planté pendant la nuit. Vous l’avez redémarré avant la décision suivante, n’avez vu aucune erreur et avez supposé qu’il avait repris là où il s’était arrêté. Puis il a passé un ordre d’achat pour un actif que vous possédiez déjà. Vous voulez savoir si la stratégie a un bug.
C’est possible. Mais vérifiez d’abord si le processus redémarré connaît les mêmes informations que le compte paper. Un redémarrage est un problème de récupération d’état : les positions, les liquidités, les ordres ouverts et toute mémoire de stratégie qui influe sur la prochaine décision doivent concorder. Remettre le code en marche, c’est la partie facile.
Que croyait la stratégie avant le plantage ?
Notez la dernière décision prise par le processus avant son arrêt. Pour chaque instrument négocié, consignez la position visée, la position réelle du compte, les ordres en attente et l’état du signal qui influera sur la prochaine action. Si ces informations n’existent pas, vous ne pouvez pas savoir si le redémarrage a restauré l’état ou s’il a simplement initialisé une nouvelle stratégie.
Imaginons que votre stratégie horaire achète une unité lorsque son signal de tendance devient positif, puis conserve la position jusqu’à ce qu’il devienne négatif. Le processus soumet l’achat à 14:00, mais plante avant d’enregistrer que l’ordre a été accepté. La plateforme paper l’exécute. Au redémarrage, la stratégie ne voit aucune position enregistrée et le signal est toujours positif ; elle soumet donc un nouvel achat. Le signal se comporte de façon cohérente. C’est sa mémoire de ce que détient le compte qui est périmée.
C’est pourquoi il faut réconcilier la position actuelle du compte avec l’état de stratégie enregistré avant d’autoriser de nouveaux ordres. Un instantané local peut être utile, mais le compte ou la plateforme fait foi pour déterminer ce qui a réellement été exécuté.
Quels états doivent être conservés après un redémarrage ?
Commencez par les états susceptibles de modifier le prochain ordre. Conservez un enregistrement durable, horodaté et versionné à chaque mise à jour ; faites-en une copie avant de modifier votre logique de récupération afin de pouvoir reproduire le plantage plus tard.
| État | Pourquoi c’est important | Vérification de récupération |
|---|---|---|
| Positions et liquidités | Elles déterminent l’exposition et le pouvoir d’achat disponible | Comparer les valeurs enregistrées avec celles du compte paper |
| Ordres ouverts | Un ordre peut avoir été exécuté pendant l’arrêt du processus | Interroger le statut des ordres et réconcilier les exécutions partielles |
| Mémoire des signaux | Les croisements, les périodes de refroidissement et les durées de détention peuvent s’étendre sur plusieurs décisions | Restaurer les dernières données d’entrée de décision validées |
| Dernier événement traité | Il détermine à quel point la stratégie reprend la lecture des données | Rejouer les événements suivants sans les appliquer deux fois |
La mémoire des signaux est facile à négliger. Une stratégie qui négocie sur un croisement peut conserver la valeur de l’indicateur de la veille pour détecter un nouveau croisement. Si elle démarre avec une valeur vide, elle peut prendre une condition déjà présente pour un nouvel événement. Un délai de refroidissement pose le même problème : le redémarrage ne doit pas réinitialiser discrètement une règle qui devait persister.
Comment rendre la récupération reproductible ?
Attribuez à chaque ordre un identifiant client stable, dérivé de l’exécution de la stratégie et de la décision à l’origine de l’ordre. Si le processus réessaie après un délai d’attente, il peut vérifier si cette décision a déjà créé un ordre au lieu d’en passer un doublon. N’enregistrez les changements d’état qu’après confirmation de l’événement correspondant dans le compte, et conservez les identifiants des ordres et des exécutions qui expliquent ces changements.
Testez ensuite le scénario à l’origine de l’incident. Faites exécuter une décision à la stratégie, enregistrez l’état, arrêtez-la, puis restaurez-la avec les positions et l’historique des ordres du compte paper. Comparez la décision suivante et les ordres qui en résultent avec ceux d’une exécution ininterrompue. Recommencez avec un ordre partiellement exécuté et avec un plantage survenu entre la soumission et l’accusé de réception. L’exécution reprise ne doit ni inventer une nouvelle position ni répéter une action déjà terminée.
Tenez un journal de récupération : dernier événement traité, heure de l’instantané du compte, statuts des ordres ouverts, version de stratégie restaurée et première décision après le redémarrage. Vous pourrez ainsi auditer ce qui s’est passé au lieu de vous contenter de constater que « le processus est reparti ».
À quoi vous fier après le redémarrage ?
Ne faites confiance au processus que lorsque l’état du compte et celui de la stratégie concordent, que le statut des ordres en attente est connu et que la décision suivante correspond à celle attendue d’une exécution continue. Si vous ne pouvez pas expliquer un écart, suspendez la soumission d’ordres paper et examinez la séquence des événements. Le fait qu’un processus soit en marche ne prouve pas que la stratégie a été récupérée.
Vous avez déjà tiré quelque chose d’utile de ce plantage : il a révélé une hypothèse à laquelle votre exécution habituelle n’avait jamais été confrontée. Faites du redémarrage un scénario reproductible et vous saurez ce dont votre stratégie se souvient avant de lui demander de négocier à nouveau.
← Tous les articles
