Les données tick ne sauveront pas votre backtest — elles l’aggravent pour la plupart des stratégies

Le conseil habituel, c’est : si vous voulez un backtest fiable, procurez-vous des données tick. À mon avis, ce conseil est mauvais pour la plupart des stratégies, et le suivre rend généralement le backtest moins bon, pas meilleur. Non pas parce que les données tick sont inexactes — c’est ce qu’on peut obtenir de plus précis — mais parce que la plupart des gens remplacent la rigueur par la résolution, alors que ce n’est pas la même chose.

Voici comment ça se passe. Un chercheur construit une stratégie sur des bougies de 1-minute, obtient un Sharpe qui lui plaît, puis quelqu’un — un mentor, une publication sur un forum, ou ses propres doutes persistants — lui dit que son backtest n’est pas fiable parce qu’il repose sur des bougies. Il reconstruit alors tout son pipeline avec des données tick : chaque transaction, chaque mise à jour de cotation, horodatée à la microseconde. Le backtest ralentit, le code devient trois fois plus complexe et le Sharpe... bouge à peine, ou évolue dans un sens que personne ne peut expliquer. Il le met quand même en production, parce que les données tick donnent une impression de rigueur, et cette impression n’est pas la rigueur.

Ce que la résolution tick vous apporte réellement

Les données tick indiquent l’ordre et le prix de chaque transaction et, si vous payez pour cela, de chaque mise à jour du carnet d’ordres. C’est une information réelle. Elle permet de reconstituer la position dans la file d’attente, d’estimer la probabilité d’exécution à un niveau de prix donné et de repérer la sélection adverse — c’est-à-dire si le marché évolue contre vous juste après votre exécution hypothétique. Tout cela compte énormément si votre horizon de détention se mesure en secondes et votre avantage en fractions de tick.

Mais la plupart des stratégies que nous voyons chez Stratmill — et celles que les chercheurs particuliers et semi-professionnels utilisent réellement — conservent les positions de quelques minutes à plusieurs jours. À cet horizon, la fiabilité de votre backtest ne dépend pas de la modélisation de la 40e transaction d’une minute donnée. Elle dépend de la modélisation du spread, du taux de funding, de la courbe de slippage et du fait que votre ordre limite se trouve derrière les ordres des autres dans la file d’attente. Vous pouvez vous tromper sur ces 4 points avec des données tick et les modéliser correctement tous les 4 avec des bougies de 1-minute. La résolution et la fiabilité sont deux choses indépendantes.

C’est ce dernier chiffre que les gens sous-estiment. Un backtest au tick, ce n’est pas « le même backtest avec plus de lignes ». Sur la plupart des plateformes, les transactions arrivent dans un ordre différent de celui de leur horodatage à l’ingestion, sont corrigées après coup, sont réparties entre plusieurs fragments du moteur de correspondance et — sur plusieurs plateformes dont nous avons ingéré les données — sont parfois dupliquées ou entièrement perdues lors d’une reconnexion. Construire un pipeline tick plus fiable qu’un pipeline de bougies bien conçu, et pas seulement plus granulaire, représente un véritable projet système. La plupart des équipes ne le font pas. Elles branchent un backtester sur un fichier tick fourni par un prestataire et s’en tiennent là. Elles ont ainsi remplacé un ensemble connu et documenté d’approximations (OHLCV) par un ensemble inconnu et non documenté (ce que fait le prestataire pour rapprocher les données tick quand ça se passe mal).

Le bruit que vous achetez

Il y a un deuxième coût, qui relève moins de l’ingénierie que des statistiques. Les transactions individuelles oscillent entre le bid et l’ask : c’est l’oscillation bid-ask, un artefact bien connu dans la littérature sur la microstructure des marchés depuis les années 1980. Si votre signal opère à une fréquence supérieure à quelques secondes, un backtest au tick peut vous faire voir une structure là où il n’y a que cette oscillation. J’ai vu un chercheur découvrir un superbe motif de retour à la moyenne dans les données transaction par transaction, qui disparaissait dès qu’il agrégeait les données en bougies de 5-secondes, parce que ce motif n’était que l’oscillation bid-ask.

Un quant que je connais — ancien teneur de marché, aujourd’hui à la tête d’un petit portefeuille crypto — me l’a formulé ainsi : « Les données tick sont une loupe. Si vous la braquez sur votre avantage, parfait. Si vous la braquez sur votre bruit, vous passerez six mois à modéliser votre bruit à la perfection. » Il backteste désormais presque tout sur des bougies de 1-seconde ou de 1-minute et ne passe aux données tick que pour répondre à la question précise : « Cet ordre limite aurait-il réellement été exécuté ? » C’est une question de probabilité d’exécution, pas de signal.

Cette distinction est la bonne approche, et c’est celle que la plupart des partisans des données tick oublient. La bonne manière d’utiliser les données tick n’est pas d’y faire tourner toute sa stratégie, mais de les employer avec discernement pour répondre aux 1 ou 2 questions auxquelles les données en bougies ne peuvent réellement pas répondre.

Quand les critiques ont raison

Cela dit, certaines stratégies exigent des données tick. Prétendre le contraire serait exagérer mon propos. Si vous faites quelque chose qui ressemble à de la tenue de marché — cotation des deux côtés, gestion de l’inventaire tick par tick, suivi de votre position dans la file d’attente à un niveau de prix précis — les données en bougies ne peuvent tout simplement pas représenter votre problème. Toute l’économie de cette stratégie se joue à l’intérieur de la minute, pas d’une minute à l’autre. Il en va de même pour l’arbitrage statistique sensible à la latence entre plateformes, où la question est littéralement « quelle transaction a eu lieu en premier ? », et pour la tenue de marché sur options avec des volumes importants, où quelques centaines de millisecondes de sélection adverse après une transaction font toute la différence. Dans ces cas, un backtest sur bougies n’est pas une simplification, c’est une erreur de catégorie : vous ne testez pas une version moins détaillée de votre stratégie, mais une stratégie différente qui porte le même nom que la véritable.

L’idée n’est donc pas que « les données tick sont mauvaises ». C’est que les réclamer permet souvent d’éviter une question plus difficile et moins séduisante : mon modèle de coûts est-il correct ? Mes hypothèses d’exécution sont-elles correctes ? Cet ordre aurait-il réellement été exécuté, ou est-ce que je suppose une exécution à un prix que le carnet ne m’a jamais vraiment proposé ? On peut répondre à ces questions avec des bougies de 1-minute, voire de 1-seconde, à condition de tenir compte honnêtement de la position dans la file d’attente et du spread. Les données tick permettent d’y répondre avec plus de précision, au prix de plusieurs fois plus de travail d’ingénierie, pour des stratégies où cette précision supplémentaire ne change rien à la conclusion. Consacrez cet effort supplémentaire aux horizons qui l’exigent réellement et laissez-le de côté ailleurs : c’est un meilleur emploi du temps d’une équipe de recherche que de choisir par défaut les données les plus granulaires disponibles parce qu’elles semblent plus rigoureuses.