Incident de bot de trading: Comment Mathieu a gelé l’exécution sans effacer les preuves

Quand un bot produit un comportement inattendu, la première mesure consiste à bloquer toute nouvelle exécution tout en conservant ses journaux intacts. Vous protégez ainsi le capital restant sans effacer les éléments nécessaires pour comprendre ce qui s’est passé.

À 6 h 12, dans sa cuisine à Lyon, Mathieu découvre trois ordres exécutés pendant la nuit. Ce graphiste indépendant, encore en chaussettes, tient son téléphone d’une main et une tasse froide de l’autre. Deux positions ont déjà touché leur stop. La troisième reste ouverte, tandis que le bot prépare un nouvel ordre.

Mathieu veut tout couper. Il hésite entre désactiver le compte, révoquer les accès et supprimer la stratégie. Chaque minute laisse pourtant une issue coûteuse sur la table: un nouvel ordre peut engager davantage de capital. Une suppression précipitée pourrait aussi faire disparaître les traces qui expliquent l’incident.

Geler l’exécution avant de chercher une explication

À 6 h 14, Mathieu choisit une action plus précise: empêcher le bot d’envoyer de nouveaux ordres. Il ne modifie ni les paramètres de la stratégie ni les journaux. Il relève séparément la position encore ouverte, car arrêter l’automatisation ne ferme pas nécessairement ce qui est déjà sur le marché.

Cette séquence compte:

1. Bloquer toute nouvelle exécution.
2. Identifier les ordres déjà transmis, ouverts ou partiellement exécutés.
3. Préserver les journaux, horodatages et paramètres actifs.
4. Décider séparément du traitement des positions existantes.

Le premier objectif n’est pas de prouver que le bot a eu tort. Il consiste à empêcher une anomalie supplémentaire pendant que les faits restent vérifiables.

Ce principe vaut aussi pour une architecture avec porte d’approbation. Une IA peut continuer à générer et mettre en attente des signaux, mais aucun ordre ne devrait partir sans décision humaine explicite. Cette séparation maintient une frontière claire entre une proposition calculée et du capital réellement engagé. C’est le même problème de contrôle abordé dans Que se passe-t-il quand un bot peut engager votre capital sans approbation?.

Les journaux sont votre seule chronologie exploitable

À 6 h 21, la tentation de Mathieu change de forme. Il veut corriger immédiatement le seuil qui semble responsable, puis relancer la stratégie pour vérifier. Ce geste aurait contaminé l’enquête: après une modification, il devient difficile de distinguer la configuration de la nuit de celle du test suivant.

Un journal utile doit permettre de reconstruire la chaîne de décision:

• les données disponibles au moment du signal;
• la version de la stratégie ou du modèle;
• les paramètres de risque actifs;
• le signal proposé et sa justification;
• l’heure de sa création;
• l’approbation éventuelle;
• l’ordre transmis, puis son état d’exécution;
• les erreurs, rejets ou nouvelles tentatives.

Une capture d’écran montre un résultat. Un journal cohérent montre la succession des décisions. Cette distinction devient décisive lorsqu’un ordre paraît incohérent après coup, mais pouvait sembler valide avec les données visibles quelques minutes plus tôt.

Préserver les preuves demande aussi de résister au récit le plus confortable. Mathieu suppose d’abord qu’un bug a ignoré son stop. Les journaux peuvent révéler une autre cause: un paramètre mal saisi, une donnée manquante, une tentative répétée ou un écart entre le prix attendu et le prix exécuté. Sans chronologie, chacune de ces explications reste une intuition.

Séparer l’incident, l’hypothèse et la décision

À 6 h 37, Mathieu ouvre son journal de trading et crée trois colonnes: « fait observé », « explication possible » et « décision ». Ce découpage l’empêche de transformer une hypothèse en certitude.

« Trois ordres ont été exécutés » est un fait. « Le modèle a sur-réagi » est une hypothèse. « Maintenir les nouvelles exécutions désactivées » est une décision.

Il note aussi les éléments qui manquent. Quel paramètre de taille de position était actif? Le signal avait-il été recalculé? Une nouvelle tentative a-t-elle suivi un rejet? L’ordre a-t-il été approuvé par une personne ou exécuté sans contrôle?

Ces questions mettent en évidence la faiblesse centrale des bots autonomes: lorsque l’exécution et l’analyse sont confondues, le système peut continuer à engager du capital pendant que vous cherchez encore pourquoi. Une porte d’approbation rompt cette boucle. Le signal reste une proposition observable, que vous pouvez accepter ou refuser selon votre plafond de perte, votre exposition totale et les conditions réelles du marché. Pourquoi Thomas refuse un signal valide illustre cette différence entre validité technique et décision acceptable.

Relancer seulement avec une règle vérifiable

À 7 h 03, la cuisine de Mathieu n’a pas changé, mais sa situation oui. Aucun nouvel ordre ne peut partir. La position ouverte est traitée comme une décision distincte. Les journaux de la nuit sont conservés, et ses hypothèses restent clairement marquées comme telles.

La relance ne devrait jamais dépendre d’un simple « ça a l’air réglé ». Elle exige une cause identifiée, une correction documentée, un scénario de test défini et une limite de risque adaptée. Si la cause reste inconnue, le bot reste gelé.

Pour un système avec approbation humaine, la reprise peut commencer par des signaux mis en attente sans exécution. Vous examinez alors la taille proposée, la perte maximale envisagée, les données utilisées et le raisonnement produit. L’objectif n’est pas de retrouver confiance par habitude. Il est de reconstruire un processus dans lequel chaque engagement de capital reste une décision consciente.

À 6 h 12, Mathieu cherchait le bouton qui ferait disparaître le problème. À 7 h 03, il possède quelque chose de plus utile: aucune nouvelle exposition automatique, une chronologie intacte et une liste précise de conditions à vérifier avant toute reprise.

Contenu éducatif, pas un conseil financier.