Un agent IA autonome est généralement construit à partir de trois modules isolés : un collecteur de données on-chain (nœuds RPC et API d'indexation), un cœur cognitif (LLM à faible latence) et une passerelle d'exécution des transactions (Action Layer). Essayer de brancher votre logique de trading sur des modèles commerciaux ultra-censurés comme GPT-4o est le meilleur moyen de voir vos clés API révoquées en pleine période de haute volatilité. Leurs filtres de sécurité internes interprètent souvent les flux de signaux de trading comme une génération de risque financier. Pour une automatisation stable, on se tourne plutôt vers des modèles open-weights non censurés (comme Llama 3.3 70B ou DeepSeek V3), déployés sur des hébergements décentralisés ou accessibles via des passerelles spécialisées comme Venice AI.
Le layer d'exécution doit être branché sur une infrastructure offrant un ping minimal. Dans le secteur des contrats perpétuels (perps), l'API d'Hyperliquid est devenue le standard absolu grâce à son fonctionnement sur un appchain L1 dédié, capable de traiter les ordres en moins de 0,1 seconde. Le cœur cognitif n'a aucun accès direct au wallet : le modèle reçoit un array de métriques de marché et renvoie une recommandation au format JSON. C'est ensuite un script Python local qui valide cette réponse par rapport à des règles de gestion des risques ultra-strictes avant de diffuser la transaction sur le réseau.
Voici le code, et pour ce qui est de la documentation de l'API Hyperliquid, ça se passe ici : https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint/perpetuals
import osimport jsonimport requestsfrom eth_account import Account# on récupère les clés depuis l'environnement, hardcoder des clés privées c'est direct l'asile
VENICE_URL = "https://api.venice.ai/api/v1/chat/completions"
VENICE_KEY = os.getenv("VENICE_API_KEY", "")
WALLET_KEY = os.getenv("AGENT_PRIVATE_KEY", "0x0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef")def get_market_data(coin="ETH"):
# on parse l'orderbook et le funding actuel directement depuis l'appchain Hyperliquid
try:
r = requests.post("https://api.hyperliquid.xyz/info", json={"type": "metaAndAssetCtxs"}, timeout=8)
res = r.json()
universe = res[0]["universe"]
ctxs = res[1]
idx = next(i for i, a in enumerate(universe) if a["name"] == coin)
return {
"ticker": coin,
"price": float(ctxs[idx]["midPrice"]),
"funding": float(ctxs[idx]["funding"]),
"oi": float(ctxs[idx]["openInterest"])
}
except Exception:
return None # si HL lag, on touche pas aux ordres, la sécurité avant toutdef ask_brain(context):
if not VENICE_KEY:
return {"action": "HOLD", "pct": 0, "leverage": 1}
headers = {"Authorization": f"Bearer {VENICE_KEY}", "Content-Type": "application/json"}
# on restreint le modèle pour éviter qu'il crache du texte inutile. on veut du JSON pur
prompt = (
"You are a trading bot execution engine. Analyze the metrics. "
"Return JSON ONLY. No markdown blocks, no text explanations. "
"Format: {\"action\": \"BUY\"|\"SELL\"|\"HOLD\", \"pct\": int, \"leverage\": int}"
)
payload = {
"model": "llama-3.3-70b-instruct",
"messages": [
{"role": "system", "content": prompt},
{"role": "user", "content": f"Data: {json.dumps(context)}"}
],
"temperature": 0.1 # on kill les hallucinations et la créativité
}
try:
r = requests.post(VENICE_URL, json=payload, headers=headers, timeout=12)
out = r.json()["choices"][0]["message"]["content"].strip()
# on dégage les backticks si le modèle a buggé en ajoutant du formatage markdown
if "```" in out:
out = out.split("```")[1].replace("json", "").strip()
return json.loads(out)
except Exception:
return {"action": "HOLD", "pct": 0, "leverage": 1}def filter_limits(decision, current_price):
# garde-fou strict. si le modèle pète un câble, le code le recadre
if decision["action"] not in ["BUY", "SELL"]:
return None
# on limite le levier à 3x et le volume à 5% max du wallet
leverage = min(int(decision.get("leverage", 1)), 3)
pct = min(int(decision.get("pct", 0)), 5)
if pct <= 0:
return None
# on intègre 0.3% de slippage pour être sûr que l'ordre passe instantanément
slip = 1.003 if decision["action"] == "BUY" else 0.997
return {
"coin": "ETH",
"side": decision["action"],
"px": round(current_price * slip, 2),
"lev": leverage,
"size_pct": pct
}def run_pipeline():
if WALLET_KEY != "0x0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef":
acc = Account.from_key(WALLET_KEY)
print(f"[+] Bot initialisé pour l'adresse : {acc.address}")
ctx = get_market_data("ETH")
if not ctx:
print("[-] Pas de connexion avec HL.")
return
raw_decision = ask_brain(ctx)
final_order = filter_limits(raw_decision, ctx["price"])
if final_order:
print(f"[+] Ordre généré : {json.dumps(final_order)}")
else:
print("[*] En attente de conditions idéales, position inchangée.")if __name__ == "__main__":
run_pipeline()Automatisation du Yield Farming sur les marchés de lending
Dans le secteur DeFi spot, les agents sont généralement entraînés à piloter des positions de dette dans des pools isolés (comme Morpho Blue ou Fluid) ou sur ce bon vieil Aave V3. Le plus gros casse-tête ici, c'est de monitorer en continu le Health Factor (HF), sous peine de voir sa position se faire atomiser par les liquidateurs. Le bot interroge le contrat PoolLens via RPC et calcule le risque selon la formule classique :
Si le marché plonge et que le collatéral commence à perdre sa valeur, l'agent doit initier de lui-même un désendettement partiel (Self-Deleverage). Pour éviter de cramer ses propres fonds, il va déclencher des flash loans via Balancer ou Uniswap V3. C'est un point critique, car sur un protocole comme Morpho, la pénalité de liquidation est énorme : on peut perdre 10 à 15 % de la taille totale de sa position en une fraction de seconde.
Si votre bot s'amuse à sauter de pool en pool pour chasser les meilleurs APY, il faut impérativement hardcoder un calcul ultra-précis du coût du gaz. Le script va ping l'API de ParaSwap ou 1inch, récupère les cotations et soustrait de la rentabilité théorique les pertes liées au gaz et au slippage. Si le transfert de stablecoins, par exemple d'Arbitrum vers Base, met plus de 72 heures à être amorti, on envoie balader le modèle. La transaction est bloquée au niveau de la logique de base du script, même si le LLM est en pleine euphorie et pousse cette opportunité au max dans ses prédictions.
Matrice de risque pour systèmes autonomes
Laisser un wallet sous le contrôle total d'un LLM est un suicide financier pur et simple. Les réseaux de neurones traînent avec eux un tas de bugs spécifiques totalement inconnus dans le monde du trading algorithmique traditionnel.
- Empoisonnement des flux (Data Poisoning)
Des attaquants se mettent à wash trader des volumes fictifs on-chain ou à spammer des fake news. L'IA interprète ça comme le « début d'une tendance haussière massive » et court acheter au plus haut.
Solution – Le cross-checking multi-sources. Le script doit impérativement confronter le bruit textuel des réseaux sociaux avec les volumes réels de transactions récupérés directement de la blockchain. S'il n'y a pas de vraie liquidité dans le pool, on ignore. - Rupture de formatage (JSON Break)
Le marché part en vrille, la volatilité explose, le modèle panique, oublie de fermer une guillemet, insère du texte inutile dans sa réponse ou corrompt le JSON. Le script crash, le bot est offline.
Solution – Un bloc try/except ultra-strict. Moindre erreur de syntaxe lors du parsing de la réponse du LLM doit immédiatement faire basculer le bot en mode HOLD (statu quo). La sécurité des fonds prime sur tout le reste. - Frontrunning lors des rebalancements
Le bot pousse une transaction pour migrer de la liquidité dans le mempool public, où les bots MEV le guettent déjà. Résultat : on se prend un slippage monstrueux et on se fait rincer.
Solution – Utiliser des RPC privés. Toutes les transactions doivent être envoyées exclusivement via Flashbots Protect ou BuilderRPC, en contournant le mempool public pour rester totalement invisible. - Latence réseau en cascade
En cas de gros dump du marché, le prix du gaz sur la L1 s'envole instantanément sur la lune. Les transactions du bot pour injecter de la marge se retrouvent bloquées en attente, et la position se fait liquider proprement.
Solution – Garder une marge de sécurité en gaz et en liquidités. On garde toujours 15 à 20 % du dépôt intacts en tokens natifs (ETH/SOL) sur le wallet, et on configure le maxFeePerGas avec un buffer d'au moins +50 % par rapport à la valeur médiane actuelle du réseau.
Il faut bien comprendre que déléguer la gestion des risques à la partie cognitive de l'agent est une erreur fatale. Le modèle est excellent dans son rôle d'analyste flexible pour dénicher des corrélations cachées ou des pools rentables. En revanche, la taille des positions, l'effet de levier maximum et les déclencheurs de sortie d'urgence doivent rester gravés dans le marbre du code source.
