Un abonne peut recevoir un signal correct et pourtant se retrouver avec une position incorrecte. La raison se trouve souvent non pas dans la logique du leader, mais entre l'envoi de l'ordre et son etat final : delai d'attente, execution partielle, annulation, nouvelle demande ou transaction manuelle sur le compte.

Pour que de tels decalages ne s'accumulent pas, le systeme de copytrading necessite une reconciliation separee. Il compare la position cible, les ordres actifs connus et l'etat reel du compte de la bourse. Aucune de ces sources ne peut etre consideree comme une image complete prise isolement.

Trois etats d'une meme transaction

Apres le signal, au moins trois etats differents existent.

L'intention du systeme. Quelle position l'abonne doit avoir apres application du coefficient de copie, des limites de risque, du lot minimum et de l'arrondi.

Les ordres envoyes mais non termines. Ils peuvent deja modifier la position, meme si le volume actuel sur le compte n'a pas encore change.

Le fait de la bourse. Ordres, executions et position que la bourse renvoie via le flux prive et les requetes REST de controle.

Comparer uniquement la cible a la position actuelle peut faire manquer un ordre en cours et envoyer un volume en trop. Se fier uniquement au journal local peut faire ignorer une transaction manuelle ou une modification survenue apres une perte de connexion. La reconciliation doit prendre en compte les deux sources.

Pourquoi la reponse a la creation d'ordre ne termine pas l'operation

Les API boursieres fonctionnent de maniere asynchrone. Une reponse reussie a la requete indique generalement que la plateforme a accepte la demande pour traitement. Ensuite, le statut de l'ordre peut changer.

Dans la documentation Bybit, les etats non remplis, partiellement executes et recemment termines sont listes pour obtenir separement les ordres ouverts et fermes. Pour des mises a jour rapides, la bourse recommande un flux WebSocket prive d'ordres. Binance transmet les changements de statut et le volume execute cumule dans l'evenement de mise a jour d'ordre. La documentation OKX decrit aussi l'abonnement au canal d'ordres et les transitions entre les etats live, filled et annulation.

On en tire une regle pratique : la reponse HTTP, l'evenement d'ordre et la position du compte sont des preuves distinctes. Pour un resultat final, il faut les relier par un identifiant stable.

Delai d'attente et repetition risquee

Un delai d'attente signifie simplement que le client n'a pas recu de reponse a temps. Il n'indique pas si la demande est arrivee au systeme de trading.

Deux scenarios sont possibles :

  • la bourse n'a pas recu la demande ;
  • la bourse a recu et meme execute la demande, mais la reponse a ete perdue en chemin.

Si on repete immediatement la demande sans verification, dans le second scenario, un second ordre apparaitra. C'est pourquoi l'integration trading utilise habituellement un identifiant client unique et un traitement idempotent cote client. Apres un resultat incertain, le systeme cherche d'abord l'ordre par identifiant ou le recupere via l'historique et le flux d'evenements. Un nouvel ordre n'est envoye que si la tentative precedente est classifiee.

C'est un principe general d'integration fiable, pas une affirmation sur l'implementation interne de CopyTrader.

L'execution partielle modifie le calcul du delta

Supposons que la position cible d'un abonne soit 1,0 BTC, la position reelle actuelle soit 0,6 BTC, et qu'un ordre d'achat ouvert pour 0,4 BTC soit deja execute a moitie.

Si la bourse a deja inclus les 0,2 BTC executes dans la position courante, il reste 0,2 BTC a executer. L'etat pris en compte est :

position reelle reste non execute des ordres actifs.

Dans l'exemple, c'est 0,8 0,2 = 1,0 BTC. Aucun ordre supplementaire n'est necessaire.

Si le systeme ne regarde que la position 0,8 BTC, il pourrait envoyer encore 0,2 BTC et apres l'achevement du premier ordre obtenir 1,2 BTC. A l'inverse, si le systeme compte tout le volume initial de l'ordre en plus de la position deja mise a jour, l'execute serait compte deux fois.

La formule precise depend du modele de position, de la direction, du mode hedge/one-way et du contrat de la bourse. Mais le principe est clair : volume execute et reste ouvert ne doivent pas etre melanges.

Cycle de reconciliation des ordres et de la position

Le cycle de reconciliation pratique comprend plusieurs etapes.

  1. Obtenir la cible. Fixer la position cible apres les regles de copie et les limites de l'abonne.
  2. Recueillir le fait des bourses. Obtenir la position actuelle, les ordres actifs et les statuts recents finaux.
  3. Associer les identifiants. Faire correspondre decision interne, ID client et ID d'ordre de la bourse.
  4. Normaliser l'etat. Tenir compte du sens, du volume execute, du reste ouvert, du pas quantite et du mode de position.
  5. Calculer les ecarts. Comparer la cible a la position reelle et au volume encore executable.
  6. Classer la cause. Delai d'attente, rejet, execution partielle, annulation, transaction manuelle, perte d'evenement ou changement de reglages.
  7. Choisir l'action. Observer, annuler le reste, envoyer un ordre correctif, bloquer la correction automatique ou transmettre la situation a un operateur.
  8. Verifier l'etat final. Apres intervention, requerir de nouveau le fait de la bourse.

La correction automatique n'est pas toujours appropriee. Si la cause est inconnue ou une activite externe est detectee sur le compte, il est plus sur d'arreter et d'afficher l'ecart que de tenter continuellement de « rattraper » la cible par des ordres de marche nouveaux.

Scenarios typiques

Observation Cause possible Que verifier avant nouvel ordre
Pas de reponse apres envoi delai d'attente ou perte de connexion ID client de l'ordre, historique des ordres et flux prive
Statut reste partially filled liquidite insuffisante ou prix limite volume execute, reste, validite et objectif actuel
Ordre annule annulation manuelle, IOC/FOK, regle de la bourse statut final et raison de l'annulation
Position differente sans ordres ouverts transaction manuelle, evenement perdu, autre mode de position historique des executions et parametres du compte
Apres reessai, le volume depasse la cible premiere tentative acceptee les deux IDs d'ordre et regle de re-envoi

Ce tableau aide a debuter l'investigation, mais ne remplace pas le contrat specifique d'une bourse. Les noms des statuts et l'ordre des evenements varient.

Ce que doit voir l'utilisateur

Le statut « transaction copiee » n'est pas suffisant. Il regroupe plusieurs etats differents et cree une fausse confiance.

Il est plus utile d'afficher separement :

  • signal recu ;
  • ordre prepare ;
  • ordre accepte par la bourse ;
  • execute partiellement ou totalement ;
  • rejete ou annule ;
  • position reconciliee ;
  • ecart detecte et action requise.

Pour les cas contestes, un journal minimal sans secret est necessaire : heure, instrument, direction, volume demande et execute, prix moyen, statut final et lien vers l'identifiant interne. Les cles API et autres donnees de compte ne doivent pas apparaitre dans ce journal.

Comment ce materiel se connecte a d'autres verifications

La synchronisation des parametres repond a la question de savoir s'il est sur d'envoyer une copie de transaction avec les parametres actuels du compte. L'etude du slippage montre pourquoi un meme signal ne garantit pas un prix moyen identique. La reconciliation apres execution repond a une troisieme question : l'etat reel correspond-il a ce que le systeme voulait creer.

Ces controles ne suppriment pas le risque de marche. Ils distinguent les causes d'ecarts et fournissent a l'operateur des preuves pour une action correcte.

Ce materiau est a caractere educatif et decrit les principes generaux des integrations de trading. Il ne constitue pas une garantie d'execution specifique, une caracteristique de toutes les plateformes connectees ou une recommandation d'investissement.