Sécurité bot crypto : clés API, 2FA et arrêt d’urgence

Désactiver les retraits sur une clé API ne suffit pas à protéger ton capital. Une clé autorisée à trader peut encore déclencher des opérations non souhaitées. La double authentification de ton compte ne supprime pas non plus les droits d’une clé déjà créée. Pour sécuriser la connexion entre un bot et un exchange, il faut examiner séparément chaque accès et savoir comment l’interrompre.

Ce guide concerne un logiciel relié par API à un compte d’exchange. Il ne fournit ni réglage de stratégie, ni commande à exécuter, ni recommandation d’investissement. Les interfaces et possibilités varient selon le service, le pays et le type de compte. Les exemples servent à comprendre les contrôles ; ils ne décrivent pas un test de plateforme réalisé par DécrypteBot.

Identifier les accès avant de connecter le bot

Commence par dessiner le trajet réel : toi, ton compte chez l’éditeur du bot, la connexion API, puis ton compte sur l’exchange. Ajoute la messagerie utilisée pour récupérer chacun des comptes. Si un signal extérieur déclenche les ordres, il constitue encore un accès à inventorier. Ce dessin permet de savoir quel service contrôle chaque autorisation.

Une clé API est un moyen d’autoriser un logiciel à effectuer certaines actions. Ce n’est pas simplement un identifiant technique sans conséquence. Dans sa documentation sur la sécurité des clés API, Kraken rappelle que leur possession peut permettre des actions sensibles sur un compte, selon les permissions accordées. Le code QR permettant leur import mérite la même prudence que le secret.

Ne confonds pas la clé de l’exchange, utilisée par le bot pour agir sur le compte, avec un jeton propre au logiciel, qui peut permettre de commander le bot. Supprimer l’un ne prouve pas que l’autre a disparu. Nomme chaque accès selon son usage et note qui l’a créé, sans recopier sa valeur secrète dans ton inventaire.

Avant de continuer, tu dois pouvoir répondre à trois questions : où se trouvent les actifs, quel outil peut donner un ordre et où peux-tu retirer cette autorisation ? Si la réponse dépend d’un message privé d’un vendeur plutôt que d’une documentation vérifiable, suspends la connexion. L’incertitude sur le fonctionnement n’est pas résolue par une petite mise de départ.

Lire les permissions par action, pas par couleur de bouton

Une interface peut regrouper plusieurs droits sous une étiquette générale comme « trading ». Lis les explications associées et les produits concernés. Une autorisation utile pour le marché au comptant ne justifie pas automatiquement l’accès à la marge, aux produits dérivés, aux transferts internes ou à la gestion d’autres comptes.

La documentation Kraken sur la création d’une clé spot distingue notamment les droits de consultation, de modification et d’annulation d’ordres ainsi que les retraits. Elle donne l’exemple d’un outil de trading qui n’a généralement pas besoin de retirer des fonds. Ces libellés ne sont pas une liste à reproduire telle quelle sur tous les exchanges.

Pour chaque permission demandée, cherche une fonction précise qui l’explique. Un tableau de suivi peut nécessiter la lecture des soldes sans pouvoir placer d’ordre. Un outil d’exécution peut avoir besoin d’annuler un ordre, mais pas de créer un autre utilisateur. Lorsqu’un droit dépasse l’usage prévu, vérifie si le service fonctionne sans lui plutôt que de tout activer pour faire disparaître une erreur.

Garde une trace non sensible des permissions retenues et de la date du contrôle. Une capture peut être utile uniquement après avoir vérifié qu’elle ne révèle ni secret, ni QR code d’import, ni donnée personnelle inutile. Le document doit te permettre de comparer les droits plus tard, pas devenir une nouvelle copie exploitable de tes accès.

Comprendre pourquoi « sans retrait » ne veut pas dire « sans perte »

Le droit de retrait vers une adresse extérieure et le droit d’exécuter une transaction de marché sont différents. Un accès qui ne peut pas transférer des actifs hors de l’exchange peut néanmoins vendre un actif, acheter un autre produit ou multiplier des opérations si ses permissions le permettent. Ces opérations peuvent détériorer la valeur du compte et générer des frais.

Imagine un compte fictif destiné uniquement à une stratégie au comptant. Si un tiers obtient un accès de trading, l’absence de retrait ne l’empêche pas nécessairement de remplacer les actifs détenus par d’autres, à des prix défavorables. Cet exemple explique un risque de permission ; il ne suppose pas qu’une plateforme précise présente actuellement une faille.

La question à poser devient donc : « Quelles actions nuisibles restent possibles avec les droits accordés ? » Un accès en lecture seule expose encore des informations sur tes positions ou ton historique. Un accès de trading ajoute un risque d’exécution. Les droits de transfert étendent encore le périmètre. Aucune de ces catégories ne doit être présentée comme anodine.

Un outil fonctionnel peut également perdre de l’argent sans incident informatique : stratégie inadaptée, frais, variation du marché ou exécution différente de celle attendue. Distingue la sécurité des accès de la performance financière. Un compte correctement protégé ne garantit pas un rendement, et un bon historique de rendement ne démontre pas que ses accès sont bien protégés.

Protéger les comptes et leur récupération

Utilise un mot de passe propre à chaque service et examine les moyens d’authentification disponibles. L’ANSSI recommande l’authentification multifacteur et une analyse adaptée au contexte. Le choix ne se résume pas à cocher « 2FA activée » : regarde comment tu te reconnectes après la perte de ton appareil et qui peut modifier les facteurs enregistrés.

Un code temporaire saisi sur un faux site peut être relayé pendant sa validité. Les passkeys reposent sur une autre logique, liée au service auquel tu te connectes. La FIDO Alliance explique leur résistance à l’hameçonnage. Cela ne signifie pas que toute attaque contre le compte, la session ou l’appareil devient impossible.

La récupération fait partie du dispositif. Vérifie les appareils, adresses de récupération et facteurs de secours déjà enregistrés. Conserve les éléments de secours avec une protection adaptée, séparément des accès qu’ils permettent de restaurer. Ne supprime pas ton seul moyen fonctionnel avant d’avoir compris comment retrouver l’accès : renforcer un compte ne doit pas te pousser à une récupération improvisée.

Traite aussi la messagerie comme un accès important. Une personne qui la contrôle peut recevoir certaines demandes de réinitialisation ou masquer des notifications. Les recommandations de Cybermalveillance.gouv.fr sur le piratage de compte invitent notamment à examiner les sessions actives et les paramètres de récupération. Applique ces vérifications aux services concernés, pas seulement au tableau de bord du bot.

Vérifier la protection propre à la clé API

L’authentification de ta session web et celle des appels automatiques sont des mécanismes distincts. Un bot doit généralement pouvoir fonctionner sans que tu confirmes chaque ordre dans ton application d’authentification. Activer la 2FA du compte ne permet donc pas de conclure que chaque requête API exigera ce second facteur.

Certains services proposent des contrôles supplémentaires pour les clés API. La documentation Kraken décrit notamment une option d’authentification propre à la clé et avertit qu’il faut vérifier sa compatibilité avec le logiciel tiers. Une protection configurée sans cette vérification peut empêcher le fonctionnement attendu ; une protection absente ne doit pas être supposée présente parce que le compte web est protégé.

Évite les captures anciennes et les listes de cases copiées depuis un tutoriel générique. Vérifie la page officielle correspondant au type de clé, au produit et au compte utilisés. Les autorisations disponibles peuvent changer. Si une documentation est ambiguë, formule une question sur le droit précis auprès du support officiel, sans transmettre le secret pour obtenir une réponse.

N’entre pas les clés dans un outil d’IA pour lui demander d’analyser la configuration. Décris les permissions en toutes lettres, avec des valeurs fictives si nécessaire. Une explication utile n’a pas besoin de connaître le secret, le mot de passe ou la phrase de récupération. Le même principe vaut pour un forum, une conversation privée ou une vidéo de dépannage.

Restreindre les IP sans surestimer cette barrière

Une liste d’adresses IP autorisées limite les origines réseau depuis lesquelles une clé peut être utilisée. Elle peut empêcher un appel depuis une adresse non autorisée, mais ne protège pas contre une action issue d’une infrastructure autorisée déjà compromise. Ce filtre complète les permissions ; il ne transforme pas une clé exposée en clé sûre.

La liste pertinente dépend de l’endroit où les appels sont exécutés. Pour un logiciel hébergé chez l’éditeur, l’adresse de ton ordinateur n’est généralement pas celle du serveur qui appelle l’exchange. Pour un logiciel que tu héberges, l’adresse sortante peut dépendre du réseau et de sa configuration. N’invente pas une liste et ne la copie pas depuis une discussion non vérifiée.

Utilise uniquement la procédure documentée pour le service concerné. Si les adresses changent, vérifie l’annonce en revenant par ton accès habituel à la documentation officielle. Un message qui demande de retirer toutes les restrictions pour « réparer rapidement » la connexion doit être examiné avec prudence. Une panne de communication ne justifie pas automatiquement un élargissement permanent des droits.

Note la source de la liste et la date à laquelle tu l’as vérifiée, sans y ajouter les secrets de connexion. Si l’outil ne permet pas cette restriction, identifie explicitement cette limite et évalue si l’usage reste acceptable. L’absence d’option n’est ni une preuve de fraude, ni une raison de prétendre que la protection existe quand même.

Limiter le périmètre accessible au bot

Séparer les usages peut faciliter le suivi et la révocation des accès. Un compte ou sous-compte dédié peut aider à distinguer les actifs affectés au bot, lorsque cette fonction existe et convient à ta situation. Sa disponibilité, ses conditions et les liens avec le compte principal doivent être vérifiés ; ils ne sont pas universels ni nécessairement gratuits.

La séparation affichée dans une interface ne prouve pas une isolation complète. Examine les transferts autorisés, les droits du compte principal et, si des produits à marge sont impliqués, les règles de garantie applicables. Ne transforme pas un sous-compte en promesse de perte maximale sans comprendre ces relations. Le présent guide ne recommande pas d’utiliser du levier.

Un inventaire simple peut contenir le nom du compte, son usage, les outils connectés et la personne qui sait retirer chaque accès. Ne mélange pas dans une même entrée une connexion de consultation et une connexion d’exécution. Lorsque tu abandonnes un outil, tu peux alors retrouver l’autorisation devenue inutile sans toucher au hasard à tous les accès du foyer.

La garde d’actifs et la sécurité d’un portefeuille matériel sont d’autres sujets. Ici, le contrôle concerne ce que le logiciel peut faire sur l’exchange. Acheter un appareil de stockage ne change pas, à lui seul, les permissions d’une clé déjà active sur un compte distant. Cette distinction évite de chercher une protection dans un équipement qui n’intervient pas dans le trajet examiné.

Contrôler la connexion avant toute exécution réelle

Prépare une fiche de vérification avant de confier des droits d’exécution. Elle doit préciser le compte visé, les permissions nécessaires, les restrictions disponibles et l’endroit où tu peux révoquer l’accès. Vérifie également si une connexion précédente existe déjà : créer une nouvelle clé ne supprime pas forcément l’ancienne.

Le paper trading aide à comprendre les comportements d’un logiciel sans reproduire toutes les conditions du marché réel. Il ne certifie pas la sécurité du compte ni celle de l’infrastructure du fournisseur. Si le mode de démonstration permet de travailler sans secret d’exécution réel, évite de lui fournir des droits dont il n’a pas besoin.

Une erreur de connexion doit être interprétée avant d’être corrigée. Elle peut venir d’une restriction, d’un compte incompatible ou d’un changement de service. Ne réponds pas systématiquement en activant toutes les permissions. Conserve le message d’erreur non sensible et cherche son explication officielle ; l’objectif est une connexion comprise, pas seulement un voyant vert.

Les automatismes supplémentaires méritent leur propre contrôle. Si tu utilises un webhook TradingView, identifie ce qui peut envoyer un signal et comment tu interromps ce chemin. Une connexion exchange-bot bien réglée ne garantit pas que tous les signaux qui arrivent au bot sont souhaités ou correctement interprétés.

Préparer la différence entre pause, révocation et fermeture

« Arrêter » peut signifier plusieurs actions. Mettre un bot en pause peut empêcher de nouveaux traitements sans supprimer les ordres déjà transmis. Révoquer une clé retire un accès, mais ne revient pas sur les transactions exécutées. Supprimer une connexion dans un logiciel peut encore avoir d’autres conséquences sur son historique ou ses paramètres.

La notice officielle 3Commas sur la suppression des clés et des connexions distingue ces opérations et décrit leurs conséquences propres. Il faut lire la version correspondant à ton outil avant d’effacer une connexion. Cet exemple documentaire ne constitue ni une recommandation commerciale ni une validation de la sécurité actuelle du produit.

Prépare une procédure qui indique où consulter les ordres et positions directement auprès de l’exchange. Ne suppose pas que la liste du bot reste à jour après une perte de connexion. Les ordres déjà acceptés peuvent continuer à exister ; certains mécanismes de protection peuvent également dépendre d’un logiciel désormais déconnecté. Le comportement exact relève de la documentation du service.

La décision de fermer une position a des conséquences financières et ne se confond pas avec le retrait d’un accès compromis. En cas de doute, utilise l’assistance officielle pour comprendre l’état du compte. Une checklist utile distingue ce qui bloque un accès, ce qui conserve des preuves et ce qui modifierait les actifs, au lieu de tout regrouper sous « supprimer le bot ».

Réagir à une clé exposée, avec ou sans accès au compte

Si un secret a été publié ou transmis à un destinataire non prévu, traite-le comme exposé. Effacer le message ou rendre un dépôt privé ne prouve pas qu’aucune copie n’a été faite. La documentation GitHub sur les données sensibles place la révocation ou la rotation du secret avant le nettoyage de l’historique. Ce principe évite de conserver un accès valide pendant que tu recherches toutes ses copies.

Si tu peux accéder au compte depuis un appareil fiable, utilise l’interface officielle du service qui a délivré la clé pour révoquer l’accès concerné. Vérifie ensuite les autres accès et les opérations récentes. Ne considère pas le changement du mot de passe du bot comme une preuve que la clé de l’exchange a été annulée : la confirmation doit venir du bon service.

Si tu n’as plus accès au compte, passe par sa procédure officielle de récupération ou d’urgence. Explique qu’une autorisation API est suspecte et demande quelles restrictions peuvent être appliquées. Ne promets pas à toi-même un gel immédiat ou une récupération des actifs : le support doit confirmer ce qu’il a effectivement pu faire. Note les références et heures des demandes.

Conserve les informations utiles à l’analyse : service concerné, moment de l’exposition, identifiant non secret de la clé si disponible, opérations suspectes et réponses du support. N’envoie pas le secret dans le ticket. Pour les démarches en cas de préjudice, Service Public présente les recours après un piratage de compte. Ne suppose pas qu’un dispositif de plainte en ligne couvre automatiquement tous les incidents crypto.

Examiner les alertes et les traces sans créer une nouvelle fuite

Les notifications peuvent signaler une nouvelle connexion, une clé créée ou une opération inattendue. Vérifie celles réellement proposées par tes services et où elles arrivent. Une absence d’alerte ne démontre pas une absence d’activité : le fournisseur peut ne pas notifier chaque événement ou la messagerie peut filtrer le message.

Prépare une façon de consulter l’historique depuis l’interface officielle, indépendamment des liens reçus par email. Pour un compte sur un exchange centralisé, une surveillance d’adresse sur une blockchain ne remplace pas nécessairement les mouvements internes du compte et les ordres exécutés. Choisis la trace correspondant à l’action que tu veux contrôler.

Les journaux techniques peuvent eux-mêmes contenir des données sensibles. Avant de demander de l’aide, retire les secrets et les éléments personnels sans utilité pour le diagnostic. Une capture du problème doit montrer le message et le contexte nécessaire, pas l’ensemble des onglets du navigateur ou les données de connexion ouvertes à côté.

Distingue enfin une panne, une erreur de stratégie et un accès non autorisé. Une vente inattendue ne suffit pas, à elle seule, à établir l’origine de l’incident. Compare les paramètres connus, les horaires et les actions enregistrées. Cette vérification ne doit toutefois pas retarder le retrait d’un accès dont le secret est manifestement exposé.

Une fiche de contrôle sans secret à conserver

Tu peux préparer cette fiche avant la connexion, puis la relire lorsque tu changes d’outil. Elle ne contient aucune valeur de clé. Chaque ligne doit renvoyer à une information vérifiable plutôt qu’à une impression générale de sécurité.

Une ligne sans réponse révèle un point à éclaircir. N’inscris pas « sécurisé » comme résultat général parce que quatre cases sur six sont remplies : une seule autorisation oubliée peut conserver des droits importants. Cette fiche sert à retrouver les accès et les décisions, pas à attribuer une note de sécurité au fournisseur.

Conserve aussi la date de la dernière vérification et la raison du changement. Cela permet de distinguer un réglage décidé volontairement d’un paramètre apparu sans explication. Si plusieurs personnes interviennent sur le compte, clarifie qui peut créer ou révoquer un accès afin d’éviter que l’une réactive involontairement ce que l’autre vient d’interrompre.

Reprendre seulement après avoir compris ce qui a changé

Après un incident, recréer immédiatement une clé avec les mêmes permissions peut rétablir le même problème. Vérifie d’abord les comptes, les appareils et les services qui avaient accès au secret. Si un appareil est suspect, évite d’y saisir de nouvelles informations de connexion avant son examen. Le retour à un voyant vert n’est pas une conclusion d’analyse.

Pour un remplacement planifié sans suspicion d’exposition, prépare les étapes de continuité documentées par les services. Identifie les automatismes qui seront interrompus et la manière de vérifier leur état. Pour une clé compromise, la priorité est de retirer l’accès exposé ; ne la conserve pas uniquement pour éviter une interruption confortable du logiciel.

Relis les permissions lors d’un changement d’outil, de compte ou de fonctionnalité. Une clé devenue inutile doit être supprimée, même si elle n’a jamais posé de problème apparent. Une fréquence de contrôle peut être choisie selon ton usage, mais aucun calendrier arbitraire lié à un montant de capital ne garantit qu’une clé restera sûre entre deux dates.

Le blog DécrypteBot sépare les questions de stratégie, de fonctionnement et de sécurité. Pour examiner un produit, retrouve aussi le répertoire des fiches de bots et la méthodologie du site. Ces ressources ne remplacent pas la documentation actuelle des accès. Ta première action utile reste de vérifier quelles autorisations existent déjà, avant d’en créer de nouvelles.