Remplacement de la clé API en copytrading : plan pour le propriétaire du service

Lorsque la cle API d'un abonne expire, que l'adresse IP autorisee change ou qu'il y a un soupcon de fuite, il semble suffisant d'inserer la nouvelle cle et de continuer la copie. Mais l'acces a la bourse et l'etat du compte de trading sont deux choses differentes. Le remplacement des informations ne prouve pas qu'une position ouverte a ete cloturee, qu'un ordre de protection a ete conserve, ou que l'action manquee du trader sera restauree.

Le proprietaire du service avec son audience a besoin d'un reglement bref : qui change la cle, qui est responsable des positions pendant la pause et selon quels criteres la connexion est a nouveau consideree comme active. Ci-dessous se trouve un tel plan, et non une promesse de remplacement transparent dans toute configuration.

Le remplacement planifie et le soupcon de fuite sont des cas differents

Lors d'une maintenance planifiee, on peut convenir a l'avance d'un moment et verifier l'etat du compte. En cas de suspicion de compromission, la priorite est autre : le proprietaire du compte revoque la cle suspecte par les moyens de la bourse et verifie la securite du compte. Il ne faut pas laisser un potentiel attaquant avoir acces pour la continuite de la copie.

Le droit de retrait desactive ne rend pas la cle de trading inoffensive : l'autorisation de trader permet de modifier l'exposition sur le marche. Par consequent, le nouveau secret n'est pas envoye a l'administrateur par messagerie, ni place dans un ticket, ni montre dans une capture d'ecran. Le participant le saisit lui-meme dans les champs securises prevus a cet effet.

Si la cle a pu etre divulguee, le plan habituel ci-dessous est complete par la procedure de securite de la bourse. Il ne faut pas retablir la connexion tant qu'on ignore qui a egalement acces au compte.

Avant le remplacement, determinez ce qui est connecte

Notez la bourse, le compte ou sous-compte necessaire, le marche et l'utilisateur du projet. La nouvelle cle doit correspondre au meme compte suppose : un nom de connexion similaire ne le garantit pas. Verifiez separement si l'ancienne cle est utilisee par un autre robot ou service. Sa revocation peut interrompre non seulement la copie.

Le proprietaire du projet et l'abonne doivent avoir une reponse commune a trois questions :

• Quelles actions de trading peuvent se produire durant les travaux ?
• Qui surveille les positions et ordres existants ?
• Que faire si la verification de la nouvelle connexion echoue ?

Ne promettez pas un mode « nouvelles entrees stoppees, sorties continues » tant qu'il n'est pas confirme pour un projet specifique. Arret de la copie et cloture de position sont traites separement : ce ne sont pas une seule operation.

Conservez l'etat initial sans les secrets

Avant le remplacement planifie, le participant verifie les positions, ordres actifs et solde disponible directement sur la bourse. Une note de travail suffit avec l'heure en UTC, l'instrument, la direction et le volume de la position, les identifiants des ordres importants et la personne responsable de la surveillance.

Ceci est un journal de maintenance, pas un stockage d'identifiants API. Si la documentation de la bourse ne precise pas le sort des ordres apres revocation de la cle, ne faites pas de suppositions : verifiez leur etat separement.

Verifiez les droits, puis l'etat du trading

Creez une nouvelle cle selon les instructions actuelles de votre bourse. Les autorisations doivent correspondre au marche requis ; le droit de retrait n'est pas necessaire pour CopyTrader. Si la restriction par IP est utilisee, les adresses actuelles de connexion sont precisees aupres du service, pas prises dans d'anciens echanges.

La instruction de connexion CopyTrader decrit la verification des cles dans les reglages utilisateur. Cela aide a detecter une erreur d'acces, mais ne confirme pas que toute la periode de pause a ete correctement traitee. L'ordre exact de sauvegarde des nouvelles informations et de reactivation doit etre clarifie pour votre configuration avant de modifier.

Apres verification d'acces, comparez les positions et ordres actuels en bourse avec l'enregistrement initial. Y a-t-il une execution inconnue ? Un ordre susceptible de modifier la position est-il reste ? Des actions du trader ont-elles eu lieu durant la deconnexion ? N'activez pas la synchronisation comme un test anodin : elle peut entrainer des operations de trading.

Exemple : la cle est remplacee, mais le travail n'est pas encore termine

L'abonne avait une position ouverte et un ordre de protection. Pendant le remplacement, le trader a diminue son volume. La nouvelle cle passe la verification, mais l'abonne a toujours la position precedente. Ce n'est pas une raison pour repeter manuellement l'action immediatement : il faut d'abord etablir quels ordres ont deja ete envoyes et ce qui a ete effectivement execute.

L'operateur fixe les limites de la pause et transmet pour analyse l'heure, l'instrument et les identifiants d'operations sans secrets. La reconciliation des ordres et positions aide a comprendre les faits d'execution ; elle ne peut etre remplacee par un statut API vert.

Quand cloturer la demande de maintenance

Le travail est termine lorsque le compte et droits necessaires ont ete verifies, les positions et ordres restants connus, l'ordre de gestion future convenu et l'ancienne cle revoquee selon le plan adopte. Cette derniere est confirmee aupres de la bourse, pas seulement par la suppression des identifiants dans le service.

Pour l'audience, il est pratique de preparer en avance une fiche : ou saisir la nouvelle cle, quoi ne pas envoyer au support et quelles informations joindre en cas d'erreur. CopyTrader fournit l'infrastructure pour votre service, pas des abonnes prets a l'emploi : un ordre de maintenance clair reste une partie du travail du proprietaire du projet. Une telle procedure n'elimine pas le risque de marche, mais aide a ne pas confondre un acces retabli avec une gestion de compte restauree.