1. Point de départ : l’automatisation n’est pas un « placement d’ordres plus intelligent »
Les quatre premières leçons ont défini l’IA dans des tâches de recherche comme le traitement d’informations, la formulation d’hypothèses, le support au backtesting et l’interprétation d’événements. Dès que l’exécution entre en jeu, le profil de risque change : les erreurs ne sont plus de simples résumés erronés ; elles peuvent entraîner des ordres en rafale, un effet de levier inapproprié ou des transferts de fonds. Les incidents courants ne proviennent pas d’une erreur du modèle, mais de permissions trop larges, de points de contrôle absents, d’environnements non sécurisés et d’une confusion entre « fonctionnement automatique » et « fonctionnement sans surveillance ».
Cette leçon ne porte pas sur l’écriture de scripts plus complexes, mais sur les limites strictes à maintenir lors de l’intégration de l’automatisation. Le principe central se résume ainsi : l’automatisation exécute des règles prédéfinies, elle ne les redéfinit pas ; toute modification des règles, des anomalies d’environnement ou des limites de fonds doit toujours rester soumise à un droit de veto humain.
2. Permissions API : le strict nécessaire, pas tout en même temps
Les clés API d’échange sont généralement segmentées par permission : lecture seule, trading au comptant, trading de produits dérivés et retraits. Les incidents typiques incluent : activer trop de permissions par commodité, utiliser la même clé pour la recherche et le trading en direct, stocker les clés dans des dépôts de code ou des documents partagés, et ne pas renouveler ni lier de listes blanches IP.
Une conception plus robuste des permissions comprend :
-
Des clés en lecture seule pour la récupération des données de marché, la réconciliation et la surveillance – physiquement séparées des clés de trading.
-
Les clés de trading ne doivent pas activer les retraits par défaut ; si des retraits sont nécessaires, utilisez des clés distinctes, des limites et des processus d’approbation.
-
Des clés différentes pour les environnements de production et de test, afin d’éviter que des scripts de test ne se connectent au trading en direct.
-
Les clés sont renouvelées régulièrement et révoquées immédiatement en cas de changement de personnel ou d’appareil.
Les permissions API doivent suivre le principe du moindre privilège : n’accorder que les permissions nécessaires à la tâche en cours – pas « activer maintenant au cas où ce serait utile plus tard ».
3. Exécution des scripts : distinguer « peut s’exécuter » de « doit s’exécuter »
Les scripts programmatiques typiques effectuent trois types de tâches : surveillance du marché, alertes de signal et placement d’ordres basé sur des règles. Les deux premières comportent un risque relativement maîtrisable ; la troisième – combinée à un effet de levier, des ordres au marché ou une logique d’échelonnement de position – augmente considérablement le risque de queue.
Une structure d’exécution sécurisée peut être définie en trois niveaux :
-
Niveau 1 : Génère des signaux uniquement – n’accède pas aux interfaces de trading.
-
Niveau 2 : Accède aux interfaces mais ne soumet que des ordres planifiés ou limités, avec des limites strictes sur chaque transaction et la taille totale de la position.
-
Niveau 3 : Autorise des instructions au marché ou à risque plus élevé, mais nécessite une confirmation manuelle ou une vérification secondaire.
Les scripts doivent également intégrer des conditions de coupure de circuit : arrêt après un seuil de pertes quotidiennes, arrêt après N ordres consécutifs échoués, arrêt si le spread ou la volatilité dépasse un seuil, arrêt si l’API renvoie un statut anormal. Les coupe-circuits ne sont pas pessimistes – ils empêchent les erreurs de se reproduire sans être détectées.
4. Limites de l’IA et de l’automatisation : les modèles ne doivent pas avoir de droits d’ordre directs
Une pratique robuste courante consiste à utiliser l’IA pour la génération de code, l’interprétation des logs et la comparaison de checklists de risques, puis à laisser des programmes indépendants, basés sur des règles, exécuter les ordres. Il n’est pas recommandé que les grands modèles produisent directement des ordres « acheter/vendre » en trading en direct et déclenchent immédiatement des transactions, en raison de sorties instables, de risques de contamination du contexte, d’un manque de résultat déterministe pour une même entrée, et de contraintes insuffisantes sur la latence ou le slippage.
Si l’IA est utilisée pour générer des scripts de trading, une revue manuelle doit être effectuée avant toute mise en production : vérifier les clés codées en dur, les limites contournées, le scaling continu dans des branches anormales ou les coupe-circuits manquants. Un code qui s’exécute ne prouve que sa validité syntaxique – pas sa préparation à la production.
5. Agents on-chain et permissions de portefeuille : plus irréversibles que les API CEX
L’automatisation on-chain ou les portefeuilles d’agents impliquent une autorité de signature, des approbations de tokens (Approve), des appels de contrats et des structures multisig. Une fois confirmées, les transactions on-chain ne peuvent généralement pas être annulées ou contestées comme sur les plateformes centralisées.
Une attention particulière est nécessaire : une approbation excessive de tokens peut permettre à des contrats malveillants de vider les fonds en une seule fois ; les portefeuilles d’agents dotés de clés privées à haute permission ou de clés de session ont des conséquences immédiates et irréversibles en cas de fuite. Les produits d’« exécution intelligente » amènent souvent à négliger que les erreurs on-chain ne bénéficient d’aucun filet de sécurité du service client.
Les bonnes pratiques incluent : minimiser les montants d’approbation, révoquer régulièrement, acheminer les opérations de grande valeur via le multisig, ne conserver que les limites opérationnelles dans les portefeuilles chauds, et séparer les gros actifs des adresses d’opération quotidienne. Les capacités des agents doivent être traitées comme des modules à haut risque – pas comme des « fonctionnalités avancées » par défaut.
Source : site officiel de Gate for AI Agent
Dans l’écosystème Gate, les produits liés à « l’IA vous aide à vérifier les marchés ou même à passer des ordres » concernent principalement Gate for AI Agent (intégré via MCP ou CLI avec Cursor, Claude, etc.). Ce n’est pas la même chose que Gate.AI Chat Assistant : Chat Assistant se concentre sur les questions-réponses ; le chemin Agent permet à l’IA d’appeler directement les données de marché, les informations de compte et les capacités de trading de Gate – une autorisation inappropriée peut effectivement déplacer des fonds.
Gate for AI Agent peut se comprendre comme quatre niveaux de capacité, du plus faible au plus élevé. Le niveau choisi dépend de votre activité : simple recherche ou trading effectif.
Niveau 1 : Données publiques de marché uniquement (risque le plus faible)
Objectif : Vérification des prix, chandeliers, profondeur de marché, liste des produits – aucune connexion à un compte Gate requise.
Adapté à : Surveillance quotidienne, rapports hebdomadaires, recoupement des faits de la Leçon 2.
Limite : L’outil renvoie des « captures d’écran de cotations », pas des « faits vérifiés ». Vous devez toujours vérifier les unités de temps, les paires, le spot par rapport aux dérivés ; ne sautez pas la vérification des sources sous prétexte que l’IA récupère les prix.
Niveau 2 : Informations sur les tokens et actualités (risque faible, mais propice aux erreurs d’interprétation)
Objectif : Présentations de tokens, indicateurs techniques, recherche d’annonces, informations de sentiment.
Adapté à : Découverte de pistes, calendriers d’événements, préparation du contexte macro/lancement de la Leçon 4.
Limite : Ce niveau « aide essentiellement à collecter du matériel » – la qualité varie des rapports médiatiques aux rumeurs communautaires. Pour les cotations, les partenariats, les actualités réglementaires – vérifiez toujours via les sites web des projets, les annonces Gate, les explorateurs de blocs ; n’ouvrez jamais de positions sur la base de simples résumés.
Niveau 3 : Opérations sur compte centralisé (risque élevé – équivalent à une API live)
Objectif : Vérifications de solde, placement/modification/transfert d’ordres, sous-comptes – nécessite une autorisation OAuth de Gate.
Adapté à : Stratégies documentées, validées par backtesting/paper trading, lorsque vous êtes prêt à en assumer les conséquences d’exécution.
Limite : Dire « achète un peu de BTC » en langage naturel peut se transformer en ordres réels. OAuth supprime la saisie manuelle de la clé API mais ne réduit pas le risque : la portée de l’autorisation doit être examinée et révoquée régulièrement dans la gestion des API Gate ; les limites par transaction, les limites de position totale, l’autorisation des ordres au marché doivent être inscrites dans vos propres règles – pas laissées à l’improvisation. Ce niveau correspond à la « couche d’exécution » de cette leçon – les coupe-circuits et les vérifications pré-négociation de la Leçon 6 doivent être appliqués.
Niveau 4 : Portefeuille on-chain et opérations DEX (risque élevé – encore plus difficile à révoquer)
Objectif : Swaps on-chain, opérations de portefeuille, interactions DApp – nécessite généralement une authentification supplémentaire via Google ou Gate OAuth.
Adapté à : Utilisateurs déjà familiers avec les stratégies on-chain et connaissant Approve/multisig/gas.
Limite : Les erreurs on-chain (mauvais transferts, sur-approbation, contrats malveillants) ne peuvent généralement pas être contestées comme un support centralisé. Les risques ici reflètent ceux des agents on-chain évoqués plus haut : privilégiez des approbations plus faibles, moins de limites, une séparation des adresses – n’activez jamais de grosses approbations à long terme simplement parce que « l’IA peut swaper en un clic ».
Comment choisir
-
Utilisez uniquement les niveaux 1 et 2 : généralement aucune connexion nécessaire – configurez MCP en tant qu’assistant de recherche.
-
Utilisation du niveau 3 : Le MCP à distance demande généralement une autorisation du navigateur au premier appel de fonction de trading ; le MCP local nécessite la configuration d’une clé API sur la machine locale – adapté à ceux qui préfèrent éviter l’authentification cloud et gérer leurs propres clés. Dans les deux cas – révoquez l’autorisation ou désactivez les clés lorsqu’elles ne sont pas utilisées.
-
Utilisation du niveau 4 : Traitez-le comme des opérations de fonds on-chain – ne le mélangez pas avec des habitudes décontractées comme « juste vérifier les prix ».
Que sont MCP et Skills ?
-
MCP est un « outil unique » : vérification des prix, placement d’ordres, lecture de solde.
-
Skills sont des « processus multi-étapes groupés » : par exemple, scanner les opportunités ou évaluer des fourchettes. Plus le bundle est rationalisé, plus l’opération est rapide, mais cela ne remplace pas les vérifications de validité par backtesting, la réduction des risques liés aux événements, ni la confirmation manuelle pré-négociation.
Trois principes de base pour utiliser Gate for AI Agent
-
Commencez toujours par « données de marché uniquement » ; n’activez les niveaux de trading/on-chain qu’une fois la stratégie et les contrôles de risque clairement définis.
-
Si l’autorisation de trading est activée – gérez OAuth comme des clés API : qui peut l’utiliser, quelles actions sont autorisées, quand révoquer.
-
Pouvoir passer des ordres ≠ devoir passer des ordres ; l’agent résout la « connexion à Gate » – pas la question de savoir si une transaction est justifiée.
7. Environnement d’exploitation et gestion des clés
La sécurité des clés et des scripts dépend autant de la conception des permissions que de l’environnement. Ne stockez pas les clés API, les phrases mnémoniques ou les clés privées dans des dépôts Git, des notes cloud, des logs de chat ou des captures d’écran. Les scripts de production doivent s’exécuter dans des environnements restreints ; les logs doivent masquer les clés. Côté appareil : des machines de trading dédiées, l’authentification à deux facteurs et des mesures anti-hameçonnage doivent être planifiées en parallèle des permissions d’automatisation. En environnement d’équipe, les rôles doivent être séparés : qui modifie les stratégies, publie les versions, détient les clés, approuve les retraits.
8. Fenêtres d’événements et automatisation : dégradation par défaut, pas d’accélération
La Leçon 4 a souligné le bruit informationnel lors des fenêtres d’événements macro et on-chain majeurs. Pendant ces périodes, l’automatisation est plus sujette à une mauvaise exécution en raison d’une volatilité anormale, d’un élargissement du spread, de retards de l’API ou de déclenchements erronés liés aux actualités. La conduite à tenir est la suivante : désactivez ou dégradez de manière proactive les ordres automatisés autour des événements – ne conservez que la surveillance et les alertes ; reprenez l’exécution basée sur des règles une fois la volatilité et les spreads normalisés. Si vous êtes connecté à Gate, à un MCP ou à un échange, les périodes d’événements doivent par défaut interdire toute nouvelle instruction de trading automatisée, sauf si la stratégie est spécifiquement conçue pour le traitement post-événement avec des limites strictes.
9. Résumé de la leçon
La Leçon 5 condense les risques de l’automatisation en trois axes : permissions minimales pour les API et les scripts en général ; exécution par niveaux et coupe-circuits ; irréversibilité et autorisation minimale pour les agents on-chain. En prenant l’exemple de Gate for AI Agent, les endpoints MCP doivent être hiérarchisés par risque : les endpoints de marché et d’information servent la recherche ; les endpoints de trading et DEX nécessitent une révision OAuth, une confirmation manuelle et une dégradation lors des fenêtres d’événements. L’IA peut améliorer l’efficacité – mais ne peut pas remplacer la validation, le contrôle des risques ni la responsabilité d’exécution. La prochaine leçon consolidera la logique de chaîne de position, la distinction des entrées, l’audit de backtesting, les limites d’événements et les règles de cette leçon dans un SOP recherche-trading-révision reproductible – incluant des éléments de checklist hebdomadaire pour les connexions Gate MCP.
