Trading quantitatif systématique

Ce qu'est le trading quantitatif systématique, et ce qu'il n'est pas

Le trading quantitatif systématique consiste à prendre des décisions de trading à l'aide de règles écrites, codées et appliquées de manière constante, plutôt qu'au cas par cas. Ces règles sont généralement issues de l'analyse statistique des données de marché. Leur propriété essentielle est que les mêmes entrées doivent produire la même décision à chaque fois. Cette constance est la principale force de la méthode, mais aussi la source de la plupart de ses risques.

Un processus systématique n'est pas pour autant un processus rentable, et il ne supprime pas l'incertitude. Une règle peut être appliquée avec une discipline parfaite et rester fausse, car les marchés évoluent, les données contiennent des erreurs et l'exécution correspond rarement aux hypothèses du modèle. Avant d'agir sur une approche systématique, la question utile n'est pas de savoir si une règle paraît bonne sur le papier. Il s'agit de savoir si l'ensemble du système qui l'entoure peut être borné, observé, supervisé et testé à nouveau.

IMRYN publie des contenus sur l'infrastructure de trading et l'exécution sur plusieurs plateformes à titre pédagogique, et non comme conseil en investissement. La suite de cet article adopte le même cadre. Elle aborde les questions opérationnelles qu'un lecteur technique devrait se poser, sans juger si une stratégie mérite d'être suivie.

Des limites de risque explicites avant la stratégie

Dans un dispositif systématique bien conçu, les limites de risque sont formalisées comme des contraintes strictes que la stratégie ne peut pas contourner. Les limites courantes comprennent une taille de position maximale par instrument, des plafonds d'exposition brute et nette, une perte maximale par jour ou par période, des limites de fréquence d'ordres et des contrôles d'écart de prix qui rejettent les ordres trop éloignés d'un prix de référence. L'essentiel est que ces limites soient explicites et appliquées par la machine. Elles ne doivent pas rester des attentes informelles dans la tête de quelqu'un.

Un test concret consiste à se demander ce qui se passe lorsque la logique de la stratégie se comporte mal. Si un bug génère une série d'ordres surdimensionnés, la couche de limites doit les bloquer quelle que soit l'intention de la stratégie. Des limites vérifiées uniquement par la stratégie elle-même ne sont pas de véritables contrôles indépendants. L'architecture doit séparer la décision de ce qu'il faut trader de la décision d'autoriser ou non un ordre.

Les limites ont aussi besoin de responsables et d'un processus de modification. Chaque seuil doit avoir une personne responsable, les modifications doivent être journalisées, et l'assouplissement d'une limite doit faire l'objet d'un examen plus strict que son renforcement. Sans cette discipline, les limites dérivent à la hausse après les bonnes périodes, précisément au moment où l'excès de confiance coûte le plus cher.

Exécution observable : comparer l'intention et la réalité

La décision simulée d'un modèle et l'exécution réellement obtenue sont deux événements distincts. Le slippage, les exécutions partielles, les ordres rejetés, la latence, les pannes de plateforme et les écarts de frais creusent un écart entre les deux. Une exécution observable signifie que cet écart est clairement visible, pour chaque ordre, en temps quasi réel. Idéalement, il est aussi possible de reconstituer après coup pourquoi chaque ordre a été envoyé, vers où il a été routé et quelle réponse a été reçue.

Lorsque l'exécution s'étend sur plusieurs plateformes, l'observabilité compte encore davantage, car l'état est dispersé. Les positions, les ordres ouverts et les soldes doivent être rapprochés des registres propres à chaque plateforme, et pas seulement de la vue interne du système. Un écart non détecté pendant des heures peut transformer une petite erreur opérationnelle en exposition importante.

Les signaux utiles comprennent la qualité d'exécution par rapport à un indice de référence défini, les taux de rejet et d'annulation, le délai entre la décision et l'accusé de réception, ainsi que les écarts de rapprochement. Les suivre en continu, avec des alertes liées à des seuils clairs, fait de l'exécution non plus une boîte noire mais un objet sur lequel une personne peut raisonner.

La supervision humaine dans une boucle automatisée

L'automatisation ne supprime pas le besoin d'humains. Elle change leur rôle. Dans une conception encadrée par des garde-fous, le système agit dans des limites fixées par des humains, et ces derniers conservent l'autorité pour le mettre en pause, reprendre la main ou l'arrêter. Les questions de conception clés sont de savoir qui peut intervenir, en combien de temps, et si l'intervention fonctionnera à coup sûr lorsque d'autres parties du système sont défaillantes.

Un kill switch qui dépend du processus même qu'il doit arrêter n'offre qu'une faible protection. Les mécanismes de supervision doivent être simples, testés régulièrement et, dans la mesure du possible, indépendants du code de la stratégie. Les circuits d'escalade doivent être convenus à l'avance, afin que personne ne débatte des responsabilités en plein incident.

La supervision couvre aussi les décisions prises en dehors de la boucle en production : valider de nouvelles stratégies, analyser les incidents et décider quand un modèle doit être retiré. C'est lors de ces revues que les observations accumulées sur le comportement réel doivent alimenter les limites et la conception.

Évaluation reproductible et limites des backtests

Les backtests et les simulations sont utiles pour écarter les mauvaises idées, mais ils ne peuvent pas confirmer les bonnes. Les résultats historiques, simulés ou réels, ne déterminent pas la suite. Les défaillances courantes comprennent le biais d'anticipation (look-ahead bias), le biais du survivant, le surapprentissage sur une période donnée et des hypothèses irréalistes sur les coûts et les exécutions.

La reproductibilité est le minimum requis. Avec la même version du code, le même instantané de données et la même configuration, une évaluation doit produire le même résultat. Sinon, personne ne peut dire si une variation des résultats provient de la stratégie, des données ou de l'environnement. Versionner les données, figer les dépendances et enregistrer les paramètres de chaque exécution rendent cet objectif atteignable.

L'évaluation doit aussi inclure des tests de résistance et des vérifications hors échantillon. Par exemple, tester sur des périodes mises de côté pendant le développement, faire varier les hypothèses de coûts et examiner le comportement lors de périodes historiquement volatiles. Le but n'est pas d'obtenir un chiffre plus flatteur. Il s'agit d'obtenir une image honnête des situations où l'approche ne tient plus.

Exemple : une checklist de décision avant déploiement

Voici un exemple hypothétique, qui n'est ni une recommandation ni la description d'un déploiement réel. Imaginons une équipe qui s'apprête à faire passer une stratégie systématique de la simulation à une exploitation réelle à petite échelle. Avant la mise en production, elle pourrait parcourir une checklist en oui/non et considérer chaque « non » comme une raison d'attendre.

Cette checklist illustre les quatre principes présentés plus haut. C'est un point de départ à adapter à vos propres contraintes et aux règles applicables. Ce n'est pas une norme de conformité.

• Limites de risque : les limites de position, d'exposition, de perte et de fréquence d'ordres sont-elles formalisées et appliquées en dehors du code de la stratégie ?
• Responsabilité des limites : chaque limite a-t-elle un responsable désigné et un historique des modifications journalisé ?
• Visibilité de l'exécution : chaque ordre peut-il être tracé de la décision jusqu'à l'exécution finale, y compris les rejets et les réponses des plateformes ?
• Rapprochement : les positions sont-elles automatiquement rapprochées avec chaque plateforme, avec des alertes en cas d'écart ?
• Supervision : existe-t-il un moyen testé et indépendant d'arrêter le trading, et les personnes habilitées à l'utiliser savent-elles quand le faire ?
• Reproductibilité : la dernière évaluation peut-elle être relancée à partir du code, des données et de la configuration versionnés et donner le même résultat ?
• Présentation honnête : la documentation interne indique-t-elle que les résultats simulés ne prédisent pas les résultats réels ?