Architecture

Un parcours contrôlé, de la donnée à l’exécution.

Cette page décrit le modèle opérationnel public d’IMRYN. Elle sépare la logique de décision, les contrôles de risque, les adaptateurs d’exécution et la supervision afin que chaque frontière puisse être comprise et examinée.

Éditeur
IMRYN
Dernière mise à jour
Méthode
Périmètre produit + sources primaires

Réponse courte

Réponse courte

Une architecture de trading systématique ne devrait pas permettre à un modèle d’envoyer directement une instruction non contrainte à une plateforme. Le flux visé par IMRYN est : entrée → contexte de décision → filtre de risque indépendant → adaptateur de plateforme → journal d’exécution → surveillance, avec une capacité d’arrêt humaine autour de la chaîne automatisée.

01

Périmètre public et niveau de preuve

Le modèle présenté est une description conceptuelle publique. Il ne certifie ni la disponibilité d’un environnement de production, ni un statut réglementaire, ni une tolérance absolue aux pannes. Une documentation peut expliquer des responsabilités et des interfaces ; elle ne prouve pas qu’un contrôle précis a fonctionné lors d’un événement réel. Cette preuve dépend des journaux, des essais et de la revue de l’environnement concerné.

IMRYN distingue donc les affirmations d’architecture des affirmations de performance. Une structure cohérente peut subir une perte, recevoir une donnée erronée, rencontrer un gap de marché ou connaître une défaillance opérationnelle. À l’inverse, un résultat favorable ne démontre pas à lui seul la qualité des contrôles.

  • Public : rôles, frontières, traces attendues et modes de défaillance.
  • Privé : paramètres, identifiants, détails des plateformes et dossiers d’incident.
  • Non garanti : disponibilité, qualité d’exécution, approbation réglementaire ou rendement futur.
02

Les entrées de décision restent en amont des contrôles

Un signal peut provenir d’observations de marché, d’un modèle ou de règles. Quelle que soit sa source, il doit rester une proposition contextualisée, et non une autorisation d’exécuter. Le dossier de décision devrait conserver l’horodatage, la version de la stratégie ou du modèle, l’instrument, le sens, la taille demandée et les conditions d’éligibilité utilisées.

Cette séparation distingue clairement « la stratégie a proposé une action » de « le système a accepté un ordre ». Elle fournit aussi un point de départ stable pour analyser une donnée périmée, un changement de version, des signaux contradictoires ou un comportement inattendu.

  • Écarter les entrées périmées, incomplètes ou mal formées avant l’exécution.
  • Versionner les règles et conserver le contexte nécessaire à l’explication d’une proposition.
  • Traiter la sortie d’un modèle comme une entrée faillible, jamais comme un moyen de contourner une contrainte.
03

Le filtre de risque décide si une instruction peut avancer

Le filtre de risque constitue une frontière de décision distincte. Il compare une action proposée à l’exposition courante, à l’éligibilité de l’instrument, à l’état du compte et de la plateforme, ainsi qu’aux limites configurées. Un rejet est un résultat normal ; une demande répétée ne devrait pas assouplir silencieusement une limite.

Les limites réduisent certains risques sans supprimer les risques de marché, de liquidité, de modèle, de contrepartie ou d’exploitation. Leur gouvernance doit préciser qui les modifie, quand une modification s’applique, comment elle est testée et où l’ancienne valeur est conservée.

  • Avant exécution : éligibilité, taille, exposition agrégée et fraîcheur des données.
  • Pendant l’exécution : annulation, prévention des doublons, limites de débit et arrêt d’urgence.
  • Après exécution : accusés, exécutions, rapprochement et escalade des exceptions.
04

Les adaptateurs isolent les particularités des plateformes

Les plateformes utilisent des types d’ordre, identifiants, transitions d’état et messages d’erreur différents. Un adaptateur traduit l’instruction interne acceptée tout en maintenant le lien entre la proposition, l’ordre soumis, les accusés et les exécutions.

Un délai d’attente ne signifie pas nécessairement un rejet, et une requête réussie ne signifie pas nécessairement une exécution. Les relances ne sont donc pas anodines : l’adaptateur et le rapprochement ont besoin d’une stratégie adaptée d’idempotence ou de prévention des doublons.

  • Conserver les identifiants internes et externes pendant tout le cycle de l’ordre.
  • Distinguer explicitement les états inconnus, rejetés, annulés, partiels et exécutés.
  • Escalader l’ambiguïté au lieu de la transformer en succès artificiel.
05

La surveillance et le contrôle humain ferment la boucle

La surveillance doit indiquer si les entrées sont actuelles, les propositions évaluées, les contraintes appliquées, les destinations joignables et les résultats rapprochés. Une alerte utile apporte le contexte nécessaire à une décision ; des traces durables rendent possible une revue ultérieure.

La supervision humaine ne se résume pas à une mention d’approbation. Elle exige un chemin d’arrêt clair, des droits d’accès, un responsable d’escalade et un moyen de vérifier l’état après intervention. Les seuils, secrets et configurations sensibles ne sont volontairement pas publiés.

  • La santé technique et l’état métier répondent à des questions différentes.
  • Un mécanisme d’arrêt rapide doit être testé périodiquement et son accès limité.
  • Les revues relient incidents et résultats inattendus aux changements de code, données, règles ou configuration.

Sources

Sources primaires et lectures complémentaires

Ces sources éclairent les concepts généraux de contrôle et de risque de cette page. Elles ne certifient ni ne recommandent IMRYN.

  1. Guidance on Effective Supervision and Control Practices for Algorithmic Trading Strategies

    FINRA, Regulatory Notice 15-09Recommandations sur l’évaluation des risques, les essais, la validation, la supervision, la traçabilité et les mécanismes d’arrêt rapide.

  2. Artificial Intelligence Risk Management Framework 1.0

    National Institute of Standards and TechnologyCadre volontaire structuré autour de la gouvernance, de la cartographie, de la mesure et de la gestion des risques liés à l’IA.

  3. AI Won’t Turn Trading Bots into Money Machines

    U.S. Commodity Futures Trading CommissionMise en garde contre les promesses de rendement, rappel des coûts et des limites de prédiction des outils automatisés.

FAQ

Réponses aux questions

Cette architecture prouve-t-elle qu’IMRYN ne peut pas tomber en panne ?

Non. Elle décrit des frontières de contrôle et des responsabilités visées. Aucune architecture ne supprime les risques de marché, de modèle, de plateforme, de données, de cybersécurité ou d’exploitation.

Un modèle d’IA peut-il contourner le filtre de risque ?

Le principe documenté est que la sortie du modèle alimente une couche de contrôle distincte et ne l’autorise pas à la contourner. La preuve dans un environnement donné exige sa configuration et ses traces d’audit.

Pourquoi les seuils exacts ne sont-ils pas publiés ?

Ils peuvent être sensibles, propres à un compte et susceptibles d’évoluer. La documentation publique expose les catégories de contrôle et leur gouvernance sans divulguer les valeurs opérationnelles.