Qu'est-ce que le trading algorithmique

Qu'est-ce que le trading algorithmique, concrètement ?

Le trading algorithmique consiste à utiliser des programmes informatiques pour décider, dimensionner et passer des ordres selon des règles définies à l'avance. Au lieu qu'une personne clique sur acheter ou vendre, un logiciel lit les données de marché, applique une logique écrite au préalable et envoie des instructions à une ou plusieurs plateformes de négociation. Se demander ce qu'est le trading algorithmique revient en réalité à s'interroger sur cette chaîne : qui a écrit les règles, ce que le programme a le droit de faire, et comment vérifier qu'il a bien fait ce qui était prévu.

Le terme recouvre des activités différentes. Certains algorithmes ne gèrent que l'exécution, en fractionnant un ordre important dans le temps pour réduire l'impact sur le marché, comme le font les plans pondérés par le temps ou par le volume. D'autres prennent eux-mêmes la décision de trading à partir de règles de suivi de tendance, de retour à la moyenne ou de valeur relative. Leur point commun est l'automatisation ; ce qui les distingue, c'est la part de jugement confiée au code.

Cet article est publié par IMRYN, qui diffuse des contenus pédagogiques sur l'infrastructure de trading systématique et le routage d'ordres vers plusieurs plateformes. Il explique des notions plutôt que de recommander une stratégie, et rien ici ne constitue un conseil en investissement.

Les composants qui transforment une règle en ordre

Un système opérationnel comporte généralement cinq couches : l'acquisition des données de marché, la logique de décision, les contrôles de risque, une couche d'exécution qui dialogue avec les plateformes, et la surveillance. Les lecteurs se concentrent souvent sur le signal, parce qu'il semble être la partie astucieuse, mais les défaillances peuvent aussi survenir aux jonctions : des données périmées, une position mal lue, ou une plateforme qui rejette des ordres d'une manière que le code n'avait pas prévue.

Chaque couche a besoin d'un contrat clair. La couche de données doit savoir quand des entrées sont en retard ou manquantes. La couche de risque doit pouvoir bloquer un ordre, quoi que veuille le signal. La couche d'exécution doit enregistrer ce qu'elle a envoyé, ce qui a été accusé et ce qui a été exécuté, afin que cet historique puisse être rapproché des rapports propres à la plateforme.

• Données : horodatage, lacunes et source de chaque prix utilisé
• Décision : règles écrites avec des paramètres versionnés
• Risque : limites strictes vérifiées avant chaque ordre
• Exécution : routage, types d'ordres et historique des exécutions par plateforme
• Surveillance : alertes associées à des personnes nommées capables d'agir

La qualité d'exécution, là où la stratégie rencontre le marché

Une règle qui paraît solide sur le papier peut perdre de l'argent dès que les coûts réels apparaissent : spreads, frais, slippage entre le prix visé et le prix obtenu, et exécutions partielles. Lorsque les ordres sont répartis sur plusieurs plateformes, chacune ajoute sa propre latence, ses règles et ses modes de défaillance. C'est pourquoi une exécution observable est importante : chaque ordre doit laisser une trace montrant l'intention, le moment et le résultat.

Concrètement, vérifiez si un système compare les prix obtenus à une référence, comme le prix d'arrivée ou une moyenne sur la période, et si cette comparaison est visible pour les personnes responsables plutôt qu'enfouie dans des journaux. Si l'exécution ne peut pas être examinée, il n'existe aucun moyen fiable de distinguer une stratégie faible d'une mise en œuvre faible.

Limites de risque et supervision humaine sont des choix de conception

Les limites de risque explicites sont des frontières que le programme ne peut pas franchir : taille maximale de position, perte maximale par séance, plafond de fréquence des ordres, instruments et plateformes autorisés. Elles doivent être écrites, appliquées dans le code avant l'envoi des ordres, et testées. Une limite qui n'existe que dans un document de politique interne n'arrête pas un ordre qui tourne en boucle.

L'autonomie est un continuum. Un système encadré par des garde-fous peut agir seul dans certaines limites, tandis que des personnes le surveillent en continu et conservent le pouvoir de le mettre en pause, de le réduire ou de l'arrêter. IMRYN présente son approche en ces termes, une action automatisée dans des contrôles de risque définis avec une surveillance continue, et ses pages publiques de méthodologie et d'architecture décrivent où il place cette frontière. Une telle documentation décrit des contrôles prévus ; elle ne prouve pas à elle seule qu'ils fonctionnent dans un environnement réel donné. Pour tout système que vous évaluez, demandez qui peut déclencher l'arrêt, en combien de temps, et si cela a été répété.

Évaluation reproductible : lire les backtests avec prudence

Les backtests et les simulations rejouent des règles sur des données passées. Ils sont utiles pour trouver des bugs et comprendre un comportement, mais un résultat historique ou simulé décrit seulement comment une règle s'est comportée dans des conditions particulières ; il n'établit pas ce qui se passera ensuite. Les tests répétés et l'ajustement des paramètres peuvent conduire à un surapprentissage des données historiques, un piège bien connu.

Une évaluation reproductible signifie qu'une autre personne peut relancer le test et obtenir le même résultat : même instantané de données, même version du code, mêmes hypothèses de coûts et mêmes paramètres. Cela implique aussi de séparer les données utilisées pour concevoir une règle de celles utilisées pour la juger, et d'énoncer ouvertement les hypothèses de slippage. Si un résultat ne peut pas être reproduit, traitez-le comme une affirmation, pas comme une preuve.

Exemple concret : une checklist avant de s'appuyer sur un algorithme

Exemple (hypothétique) : une petite équipe envisage une règle automatisée qui négocie un contrat à terme liquide et achemine les ordres vers deux plateformes. Avant de la laisser fonctionner sans surveillance directe, elle répond par écrit aux questions ci-dessous. Chaque « non » devient une tâche à corriger, pas un risque accepté en silence.

La checklist ne dit pas si la règle gagnera de l'argent ; elle dit si l'équipe comprendra ce qui s'est passé, qu'elle en gagne ou non. C'est un seuil réaliste pour s'appuyer sur un algorithme : non pas la confiance dans les résultats, mais la confiance dans les contrôles et dans l'historique.

• Les limites de position, de perte et de fréquence des ordres sont-elles écrites et appliquées avant chaque ordre ?
• Chaque exécution peut-elle être reliée au signal, à la version des paramètres et aux données qui l'ont produite ?
• Le prix obtenu est-il comparé à une référence définie, par plateforme, selon un calendrier régulier ?
• Une personne nommée reçoit-elle les alertes, et peut-elle mettre le système en pause dans un délai défini ?
• Le backtest peut-il être relancé à partir des données et du code stockés avec des résultats identiques ?
• Les coûts, le slippage et une période hors échantillon ont-ils été inclus dans l'évaluation ?