Un agent de trading IA finira, tôt ou tard, par proposer un trade qu'il ne devrait pas faire. Pas parce que le modèle est défaillant — parce qu'un modèle de langage peut être confiant mais faux, et la confiance n'est pas un contrôle de risque. La question qui compte vraiment n'est pas « à quel point le raisonnement du modèle est-il bon », c'est « qu'est-ce qui empêche une mauvaise proposition de devenir un mauvais trade ».
C'est le sujet de cet article : la gestion du risque des agents de trading comme discipline d'ingénierie, pas comme case à cocher de conformité. Nous couvrons la pile concrète de guardrails pour agents de trading — règles de dimensionnement de position agent ia, limites de position agent de trading au niveau du portefeuille, un coupe-circuit de drawdown maximal bot de trading, des rate limits contre le surtrading, des vérifications de cohérence avant exécution, et des kill switches — et comment les tester réellement plutôt que d'espérer qu'ils fonctionnent. Si vous n'avez pas encore lu la présentation de la catégorie, commencez par Qu'est-ce que le Trading Agentique ? ; cet article est l'approfondissement de la seule partie de cette anatomie qu'un mauvais prompt ne peut pas réparer : la couche de risque.
Vérité de base avant de continuer : chaque exemple ici tourne contre l'environnement de paper trading de CoinRithm. Les agents tradent avec du mUSD virtuel contre des prix de marché réels — jamais avec de l'argent réel. Il n'y a aucun théâtre d'avertissements avant exécution dans ce qui suit ; ceci est un guide d'ingénierie pour construire un contrôle, pas un avertissement sur son utilisation.
TL;DR
- Le principe central : les guardrails vivent dans du code qui s'exécute en dehors du modèle, pas dans des instructions de prompt auxquelles on fait confiance pour que le modèle les suive. Un prompt est une suggestion ; une vérification côté runner est un rejet.
- Dimensionnement de position : plafonds de fraction fixe, dimensionnement ajusté à la volatilité, et un plafond dur par marché — choisissez-en au moins un, idéalement deux.
- Limites de portefeuille : un nombre maximal de positions ouvertes, un plafond d'exposition par classe d'actifs, et une conscience basique de la corrélation pour que cinq positions « différentes » ne soient pas un seul pari caché.
- Contrôles de perte : un stop-loss obligatoire sur chaque entrée, une limite de perte quotidienne/hebdomadaire, et un coupe-circuit de drawdown maximal qui arrête l'agent — pas seulement le trade.
- Rate limits : un plafond de trades par heure/jour. Le surtrading est son propre mode de défaillance, indépendamment du fait qu'un trade individuel ait semblé raisonnable.
- Vérifications de cohérence : cotation-avant-écriture, vérifications d'écart de prix, et détection de données obsolètes attrapent les défaillances qui ne ressemblent en rien à une « mauvaise stratégie » et tout à une « mauvaise donnée d'entrée ».
- Testez les guardrails eux-mêmes en paper trading en alimentant délibérément des cas limites. Un guardrail non testé est un espoir, pas un contrôle — et le paper trading ne peut de toute façon pas tester le vrai slippage, la vraie liquidité, ou le vrai stress.
Table des Matières
- Pourquoi les Guardrails Vivent dans le Code, Pas dans les Prompts
- La Pile de Guardrails
- Guardrails Spécifiques aux Marchés de Prédiction
- Tester Vos Guardrails en Paper Trading
- Ce Que le Paper Trading Ne Teste Pas
- Comment CoinRithm S'Inscrit Dans Ce Paysage
- Questions Fréquentes (FAQ)
Pourquoi les Guardrails Vivent dans le Code, Pas dans les Prompts
Voici le principe dont découle tout le reste de cet article : un prompt bien écrit est nécessaire et jamais suffisant. Un prompt peut dire à un modèle « ne risque jamais plus de 2 % du solde sur un trade », et la plupart du temps il obéira. Mais « la plupart du temps » est exactement l'écart qu'un guardrail existe pour combler. Un modèle peut mal lire son propre solde en temps réel, oublier une instruction antérieure sous une longue fenêtre de contexte, être poussé hors de ses règles par une entrée inhabituelle ou adversariale, ou simplement faire une erreur arithmétique tout en semblant parfaitement sûr du chiffre. Rien de tout cela n'exige un « mauvais » modèle — cela exige seulement les façons ordinaires et bien documentées dont n'importe quel modèle de langage peut être confiant mais faux sur un chiffre précis à un moment précis.
La solution est architecturale, pas motivationnelle : séparer la proposition de l'exécution. Le travail du modèle est de proposer une action — un sens, une taille, un stop, une raison. Une seconde couche, déterministe — du code pur, pas un autre appel de modèle — revalide cette proposition contre des plafonds numériques durs avant que quoi que ce soit n'atteigne le marché. Si la proposition est dans les plafonds, elle s'exécute. Sinon, elle est rejetée, point final, sans négociation et sans « laisse-moi reconsidérer ». C'est la même idée couverte au niveau de l'implémentation dans Créer Son Propre Agent de Trading Crypto : des plafonds qui vivent dans le runner, pas dans le modèle, survivent à une hallucination, une tentative de prompt injection, ou une erreur honnête exactement de la même façon — en n'étant jamais consultés pour demander la permission en premier lieu.
Traitez ceci comme le principe porteur pour tout ce qui suit : chaque guardrail de cet article n'est réel que s'il est appliqué par du code qui s'exécute que le modèle soit d'accord ou non.
La Pile de Guardrails
Une couche de risque de niveau production n'est pas une seule vérification — c'est une pile, car chaque couche attrape un mode de défaillance différent. En sauter une ne rend pas les autres redondantes ; cela laisse simplement ce trou spécifique ouvert.
Règles de Dimensionnement de Position
La première ligne de défense contrôle combien du solde un seul trade peut toucher, et il existe trois approches courantes, utilisables seules ou combinées :
- Dimensionnement en fraction fixe. La règle la plus simple et la plus auditable : ne jamais mettre plus d'un pourcentage fixe du solde actuel dans une position (par ex. 5 %). C'est facile à raisonner et facile à vérifier sur une ligne de log.
- Dimensionnement ajusté à la volatilité. Dimensionne inversement à la volatilité récente — un actif plus calme reçoit une allocation plus grande, un actif plus agité reçoit une allocation plus petite, pour le même risque cible. C'est plus réactif aux conditions mais exige que l'agent calcule ou récupère une estimation de volatilité de manière fiable, ce qui est en soi quelque chose à vérifier (voir plus bas).
- Plafonds par marché. Un plafond dur sur l'exposition à un symbole ou un événement unique, indépendamment de la formule de dimensionnement utilisée pour y arriver — de sorte qu'un bug de dimensionnement dans un calcul ne puisse pas concentrer silencieusement tout le book sur un seul nom.
Les chiffres précis comptent moins que la propriété : le plafond est un chiffre que le code vérifie, pas une cible que le modèle vise. « Ne jamais risquer plus de 2 % par trade » comme instruction de prompt est une orientation ; la même règle comme vérification avant exécution qui rejette l'ordre est un guardrail.
Limites au Niveau du Portefeuille
Le dimensionnement de position contrôle un trade. Les limites de portefeuille contrôlent la somme de tous les trades ouverts :
- Nombre maximal de positions simultanées. Un nombre dur — par ex. pas plus de 3 à 5 positions ouvertes à la fois — empêche un agent de s'étaler sur une longue traîne de petits paris difficiles à surveiller qui passent individuellement chaque vérification de taille.
- Exposition maximale par classe d'actifs. Un plafond sur l'exposition totale à, disons, un secteur ou un groupe corrélé d'actifs, de sorte que l'agent ne puisse pas maximiser cinq plafonds par marché distincts qui constituent en réalité tous le même trade.
- Conscience de la corrélation. Le mode de défaillance le plus subtil ici : cinq positions « différentes » qui bougent toutes ensemble dans un drawdown ne sont pas cinq paris indépendants, ce sont un seul pari concentré portant cinq étiquettes. Même une règle grossière — plafonner l'exposition combinée aux actifs étiquetés comme corrélés — comble l'essentiel de cette faille sans avoir besoin d'un modèle de covariance complet.
Contrôles de Perte
Le dimensionnement limite combien peut être perdu par trade isolément. Les contrôles de perte limitent combien peut être perdu au global avant que l'agent ne soit forcé de s'arrêter :
- Un stop-loss obligatoire sur chaque entrée. Pas optionnel, pas « généralement » — un ordre sans stop-loss ne devrait tout simplement pas être un ordre valide que le runner placera.
- Limites de perte quotidiennes et hebdomadaires. Une fois que les pertes réalisées sur une fenêtre glissante franchissent un seuil, aucun nouveau trade ne s'ouvre jusqu'à ce que la fenêtre se réinitialise ou qu'un humain réactive l'agent.
- Un coupe-circuit de drawdown maximal. C'est le filet de sécurité au-dessus de tous les autres : si le drawdown cumulé (réalisé plus non réalisé) franchit un seuil dur, l'agent s'arrête entièrement — pas seulement le prochain trade, toute la boucle — jusqu'à ce qu'un humain examine et réactive. C'est le guardrail qui existe précisément pour le scénario où chaque vérification plus petite a individuellement réussi et où le résultat agrégé est quand même mauvais.
Limites de Fréquence et de Débit
Le surtrading est son propre mode de défaillance — indépendamment du fait qu'un trade individuel ait semblé raisonnable. Un modèle peut se convaincre indéfiniment de faire « encore un petit trade », et les frais plus le slippage s'accumulent contre un agent à haute fréquence plus vite que la plupart des prompts ne le prennent en compte. Un plafond concret de trades par heure et par jour force une pause entre les décisions, peu importe à quel point le dernier raisonnement du modèle semble convaincant.
Deux choses valent la peine d'être notées : ce plafond concerne la discipline propre de l'agent, et il est distinct des rate limits côté venue — une API de trading aura ses propres budgets de requêtes et de débit d'écriture (exposés via des en-têtes comme RateLimit-* sur l'API agent de CoinRithm), et un agent bien construit devrait respecter les deux indépendamment. Atteindre le rate limit de la venue est le signe que le guardrail de fréquence est réglé trop lâche, pas un problème à contourner.
Vérifications de Cohérence Avant Exécution
Certaines des pires défaillances ne ressemblent en rien à une mauvaise stratégie — elles ressemblent à une mauvaise donnée d'entrée sur laquelle l'agent a raisonné avec confiance. Trois vérifications en attrapent la plupart avant qu'un ordre ne soit placé :
- Cotation-avant-écriture. Récupérez une cotation fraîche et non mutante immédiatement avant chaque trade, et refusez d'exécuter si la cotation n'est pas éligible ou est devenue obsolète. Une cotation ne change jamais l'état, donc il n'y a aucun coût à la vérifier à chaque fois.
- Vérifications d'écart de prix. Si le prix sur lequel l'agent raisonne diffère de manière significative de la cotation qui vient d'être récupérée, c'est le signe que quelque chose en amont est obsolète ou faux — rejetez et re-récupérez plutôt que de trader sur l'écart.
- Détection de données obsolètes. Une vérification d'horodatage sur les données de marché sous-jacentes. Un agent raisonnant brillamment sur un prix vieux de vingt minutes raisonne brillamment sur le mauvais monde.
Kill Switches et Escalade Humaine
Chaque guardrail ci-dessus est une règle qui rejette une action spécifique mauvaise. Un kill switch est différent : c'est la règle qui arrête l'agent, pas seulement le trade, et rend le contrôle à un humain. Les conditions qui valent la peine d'être connectées à un kill switch : le coupe-circuit de drawdown qui se déclenche, une série d'échecs consécutifs du modèle ou de propositions malformées, une série de propositions rejetées consécutives (un signe que le modèle a dérivé hors de synchronisation avec ses propres plafonds), ou une pression soutenue de rate limit venant de la venue.
La vraie question de conception honnête n'est pas « l'agent va-t-il un jour en heurter un » — il le fera, éventuellement — c'est « quand cela arrive, le système échoue-t-il vers un arrêt, ou échoue-t-il vers un haussement d'épaules ? » Un guardrail qui enregistre un rejet et laisse la boucle continuer inchangée n'a en réalité rien escaladé. L'agent devrait s'arrêter, et un humain devrait devoir le réactiver explicitement — cette friction est le but, pas un bug du workflow.
Guardrails Spécifiques aux Marchés de Prédiction
Les positions sur marchés de prédiction ont besoin de tout ce qui précède plus trois vérifications spécifiques à la façon dont ces marchés se résolvent réellement — couvertes plus en profondeur dans Comment les Agents IA Tradent les Marchés de Prédiction :
- Conscience de la date de résolution. Un marché proche de sa date de résolution se comporte différemment d'un marché avec des semaines devant lui — le peu de temps restant change ce qu'un mouvement de prix signifie réellement. Un guardrail qui traite chaque marché ouvert de manière identique dimensionnera de la même façon dans un marché qui est en fait déjà décidé.
- Vérifications d'éligibilité et d'état de règlement. Tous les événements listés ne sont pas réellement tradables au sens propre — certains se trouvent dans un état contesté ou intermédiaire entre la clôture et le règlement final. Un guardrail devrait vérifier l'état réel d'éligibilité du marché avant de dimensionner dedans, pas seulement s'il apparaît dans une liste d'événements « ouverts ».
- Limites de taille pour carnets faibles. La taille d'une position sur marché de prédiction devrait diminuer, fortement, quand le carnet derrière elle est faible. Un prix coté contre très peu de volume réel peut être déplacé par la position elle-même — un plafond de taille qui ignore la profondeur de liquidité peut transformer une petite position en paper en ce qui fixe le nouveau prix.
Tester Vos Guardrails en Paper Trading
Un guardrail que vous avez seulement lu, jamais déclenché, est un espoir — pas un contrôle. La seule façon de savoir si un plafond rejette réellement ce qu'il est censé rejeter est d'essayer délibérément de le casser.
Concrètement, cela signifie alimenter l'agent (ou sa couche de validation directement) avec les cas limites qu'il est censé attraper : une proposition légèrement au-dessus du plafond de taille, une proposition très largement au-dessus, une proposition sans stop-loss attaché, une rafale de propositions destinée à tester le rate limit, une cotation intentionnellement obsolète, une séquence de pertes destinée à approcher le seuil de drawdown. Confirmez que le rejet se produit, confirmez qu'il se produit pour la bonne raison indiquée dans le log, et confirmez que le kill switch arrête réellement la boucle plutôt que de simplement enregistrer qu'il aurait dû le faire.
Le paper trading est le bon endroit pour faire cela précisément parce qu'une proposition rejetée ne coûte rien ici. Faites tourner les mêmes cas adversariaux qui vous rendraient nerveux dans un cadre réel, exprès, jusqu'à ce que les plafonds aient réellement été exercés — pas seulement déclarés — avant de leur faire confiance pour un run autonome réel.
Ce Que le Paper Trading Ne Teste Pas
Rien de ce qui précède ne devrait être lu comme « si ça passe en paper trading, les guardrails sont prouvés ». Le paper trading est honnête sur ce qu'il vérifie et tout aussi honnête sur ce qu'il ne peut pas :
- Le vrai slippage. Les exécutions simulées se remplissent au prix coté ou à proximité ; un ordre réel dans un carnet d'ordres réel et faible peut déplacer le prix contre lequel il essaie de se remplir — quelque chose qu'un test de guardrail en paper ne fera jamais apparaître.
- La vraie liquidité. Une venue de paper ne manque jamais de contreparties. Les marchés réels le peuvent, en particulier les marchés faibles contre lesquels un guardrail est spécifiquement censé protéger.
- Le vrai stress. Les moments où les guardrails comptent le plus — un marché qui bouge vite, un flux de données en retard, plusieurs conditions de risque qui se déclenchent en même temps — sont exactement les moments les plus difficiles à répéter entièrement dans un simulateur. Le test en paper prouve que la logique est correctement câblée ; il ne prouve pas que le système se comporte de la même manière sous une pression temporelle réelle et de vraies défaillances d'infrastructure.
Un cadrage honnête : le test en paper vous dit que le guardrail se déclenche. Il ne vous dit pas que le guardrail est suffisant pour du capital réel. Ce sont des affirmations différentes, et les confondre est exactement le genre de surconfiance que tout cet article essaie de prévenir par l'ingénierie.
Comment CoinRithm S'Inscrit Dans Ce Paysage
La surface de trading agentique de CoinRithm intègre le principe « des plafonds dans le runner, pas dans le modèle » comme le comportement par défaut, pas comme un ajout optionnel. Sur le runner auto-hébergé coinrithm-agent (couvert étape par étape dans Créer Son Propre Agent de Trading Crypto), chaque action proposée est revalidée contre des plafonds déclarés — effet de levier, taille par trade, marge ouverte agrégée, positions maximales, écritures par jour, écritures par cycle, une limite de perte quotidienne, et un stop-loss obligatoire sensible au sens — avant de pouvoir s'exécuter. Le dry-run est l'état par défaut ; les écritures nécessitent un flag --live explicite. Une cotation est récupérée et vérifiée pour son éligibilité immédiatement avant chaque trade. Un kill switch désactive l'agent en cas de drawdown, d'échecs répétés du modèle, ou de cycles rejetés répétés.
Tout cela tourne contre un solde de paper unique et partagé entre spot, futures, et marchés de prédiction — du mUSD simulé, jamais des fonds réels — le même environnement décrit tout au long de qu'est-ce que le trading agentique. Une fois vos plafonds câblés et testés, la même clé et le même ensemble de guardrails fonctionnent que vous tradiez manuellement, via Claude/MCP, ou via le runner autonome. Les agents de trading qui optent pour l'Agent Arena public sont classés sur le PnL de paper réalisé, donc un ensemble de guardrails qui tient réellement se manifeste comme de la constance dans le temps — pas juste comme une affirmation dans un README. Pour la conception de stratégie une fois votre couche de risque en place, voir Stratégies pour Agents de Trading IA ; pour essayer tout cela vous-même d'abord en tant qu'humain, commencez par paper trading.
Questions Fréquentes (FAQ)
Pourquoi les agents de trading ont-ils besoin de guardrails en dehors du modèle lui-même ?
Parce qu'un LLM peut être confiant mais faux — mal lisant son propre solde, dérivant d'une instruction antérieure, ou faisant simplement une erreur de dimensionnement tout en semblant sûr de lui. Une règle au niveau du prompt est une orientation que le modèle peut ne pas suivre correctement ; un guardrail au niveau du code revalide chaque proposition contre des plafonds numériques durs et rejette tout ce qui les dépasse, peu importe comment le modèle l'a justifié.
Qu'est-ce qu'un coupe-circuit de drawdown maximal et comment fonctionne-t-il ?
C'est le guardrail de dernier recours : une fois que le drawdown cumulé — réalisé plus non réalisé — franchit un seuil préétabli, l'agent s'arrête entièrement, pas seulement le prochain trade. Il existe pour le cas où chaque vérification plus petite (taille de position, stop par trade) a individuellement réussi et où le résultat agrégé est quand même mauvais. Réactiver l'agent après un déclenchement devrait exiger une décision humaine explicite, pas une réinitialisation automatique.
Combien un trade devrait-il risquer d'un solde de paper ?
Il n'y a pas de chiffre universel, mais une discipline de départ courante est une petite fraction fixe par trade (souvent citée autour de 1-2 % risqué, avec un plafond légèrement plus élevé sur la taille totale de position), appliquée comme une vérification dure plutôt qu'une cible. Les chiffres exacts comptent moins que la propriété qu'une seconde couche déterministe les vérifie avant exécution — voir la section de dimensionnement de position ci-dessus pour les approches en fraction fixe versus ajustées à la volatilité.
Qu'est-ce que le surtrading et comment les rate limits l'empêchent-ils ?
Le surtrading consiste à placer plus de trades que ce que l'avantage d'une stratégie — s'il y en a un — peut supporter, souvent parce qu'un modèle se convainc à répétition de faire « encore un petit trade ». Un plafond dur de trades par heure ou par jour force une pause peu importe à quel point le dernier raisonnement semble convaincant, et est distinct des propres rate limits de la venue, qu'un agent devrait aussi respecter.
Quels guardrails sont spécifiques aux marchés de prédiction ?
Trois, en plus de la pile générale : la conscience de la date de résolution (un marché proche de sa clôture se comporte différemment d'un marché avec des semaines devant lui), les vérifications d'éligibilité et d'état de règlement (certains événements listés sont contestés ou déjà effectivement décidés), et les limites de taille pour carnets faibles (un prix coté contre très peu de volume réel peut être déplacé par la position elle-même). Voir Comment les Agents IA Tradent les Marchés de Prédiction pour le tableau complet.
Le paper trading teste-t-il entièrement mes guardrails avant que je leur fasse confiance pour un run réel ?
Il teste si la logique se déclenche correctement — en alimentant délibérément des cas limites (tailles au-dessus du plafond, stops manquants, cotations obsolètes, séries de pertes) et en confirmant que le rejet et le kill switch se comportent comme prévu. Il ne teste pas le vrai slippage, la vraie liquidité, ou le vrai stress d'infrastructure, tous absents par conception d'un simulateur. Considérez un guardrail vérifié en paper comme prouvé pour se déclencher correctement, pas comme prouvé suffisant pour du capital réel.
Continuez votre lecture : Comment Laisser un Agent IA Trader la Crypto en Simulation — le guide pratique étape par étape pour connecter un agent et mettre ces guardrails au travail.
Avertissement : Cet article est fourni à des fins éducatives et informatives uniquement et ne constitue pas un conseil financier ou d'investissement. Tout le trading décrit ici utilise de l'USD fictif simulé (mUSD) sur CoinRithm ; aucun argent réel, wallet, ou compte d'exchange n'est impliqué à aucune étape. Rien dans cet article ne prédit ou ne garantit la performance d'un agent, et les résultats — en paper ou autrement — ne doivent pas être traités comme une prévision de résultats futurs.
