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.
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.
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.
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.
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.
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.
- Guidance on Effective Supervision and Control Practices for Algorithmic Trading Strategies
FINRA, Regulatory Notice 15-09 — Recommandations sur l’évaluation des risques, les essais, la validation, la supervision, la traçabilité et les mécanismes d’arrêt rapide.
- Artificial Intelligence Risk Management Framework 1.0
National Institute of Standards and Technology — Cadre volontaire structuré autour de la gouvernance, de la cartographie, de la mesure et de la gestion des risques liés à l’IA.
- AI Won’t Turn Trading Bots into Money Machines
U.S. Commodity Futures Trading Commission — Mise 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.