167 stratégies, par les chiffres

Les chiffres de cet article ont été mesurés le 9 mai 2026 et sont conservés tels quels. Pour les résultats actuels, consultez notre protocole de mesure de la parité.

Chiffres mis à jour le 2026-05-09 pour refléter la nouvelle taille du corpus (167 stratégies de référence, dont 165 en parité stricte).

En mai 2026, nous annoncions : « 165 stratégies sur 167 passent la parité stricte. » Cette affirmation n’a de sens que si l’on sait ce qu’étaient ces 167 stratégies. Voici une visite guidée du corpus tel qu’il était alors.

Pourquoi un corpus compte

Sans ensemble de référence figé, la « parité » reste une impression. Vous faites tourner quelques stratégies, les résultats semblent assez proches, vous livrez. Puis un utilisateur essaie des groupes de sortie OCA ou un request.security dans une boucle, et plus rien ne concorde. Les bugs étaient là depuis le début ; vous ne les aviez simplement pas testés.

Un corpus de référence, tenu à part, change la donne. À l’époque, pour toute modification susceptible d’affecter la parité, les mainteneurs relançaient sur leurs propres machines les mêmes 167 stratégies, sur le même OHLCV canonique. Si le nombre de stratégies validées augmentait, quelque chose s’était amélioré. S’il baissait, une régression s’était glissée. Le corpus est un harnais de non-régression déguisé en galerie de backtests.

Les 167 stratégies servaient aussi d’attestation publique. Nous avons commité les sorties du moteur (nombre de trades, rendements totaux, ratios de Sharpe) dans la galerie pour que chacun puisse voir ce que le moteur produisait. Rien à voir avec un communiqué de presse qui revendique la parité.

Les trois catégories

Le 2026-05-09, les 167 stratégies se répartissaient en trois dossiers : basic, community et validation (un quatrième, parity-anomalies, contenait une sonde tenue à l’écart du décompte). Ils ne formaient pas un classement par qualité ; ils décrivaient la provenance des stratégies et ce qu’elles testaient. (Le corpus public actuel range ses 312 stratégies notées sous validation/.)

basic — 9 stratégies

La catégorie basic regroupe des types de stratégies canoniques et bien connus : croisement de moyennes mobiles, Supertrend, stochastique lent, SAR parabolique, canal de Keltner, Inside Bar, Pivot Extension et une méthode d’expansion de volatilité. Ce sont les exemples de manuel que l’on trouve dans n’importe quel cours d’introduction au trading algorithmique.

Elles figurent dans le corpus parce que c’est sur les exemples de manuel que les compilateurs cassent de la façon la plus embarrassante. Si un croisement de moyennes mobiles ne produit pas la bonne liste de trades, tout le reste devient suspect. basic sert de garde-fou élémentaire.

Les 9 stratégies basic du corpus allaient de 13 trades (la stratégie greedy, très sélective) à 7 299 trades (la stratégie d’expansion de volatilité, qui se déclenche souvent sur des barres de 15 minutes). Un écart de plus de 500× au sein de la catégorie « simple », qui en dit plus sur la sélectivité des stratégies que sur leur complexité.

community — 11 stratégies

La catégorie community regroupe des scripts Pine proposés par la communauté du trading algorithmique. Des auteurs réels, c’est une variété réelle : styles de code différents, usages différents des fonctions intégrées, cas limites différents dans la façon de câbler le dimensionnement des positions et la logique de sortie.

Parmi les 11 stratégies communautaires : un filtre RSI à 4 EMA, un détecteur de courbe Break-of-Structure, une stratégie de liquidity sweep, un système de suivi de tendance baptisé MarketShift, et d’autres. Le nombre de trades allait de 72 (VCP, une stratégie multi-signaux très sélective) à 2 643 (IES, la plus active). L’écart de rendement est large : IES a rapporté +58 430 $ sur la fenêtre de backtest et MarketShift +3 388 $, tandis que la stratégie communautaire la moins performante a perdu 678 $. Figurer dans le corpus ne dit rien de la rentabilité d’une stratégie, seulement qu’elle compile et qu’elle produit des trades.

Les scripts communautaires sont la catégorie sur laquelle la parité est la plus difficile à maintenir. La diversité des auteurs fait que ces scripts combinent des fonctionnalités Pine de façon inhabituelle, ce que les suites de validation n’anticipent pas toujours. Quand nous trouvons un nouvel écart de parité, il apparaît généralement ici en premier.

validation — 147 stratégies

La catégorie validation était de loin la plus fournie : 147 des 167 entrées du corpus. Ce sont des stratégies synthétiques conçues pour exercer une sémantique Pine précise : non pas pour être rentables, mais pour prouver qu’une fonctionnalité donnée du langage se traduit correctement en C++.

Quelques exemples de ce que ciblaient, à l’époque, certaines stratégies de validation :

• 41-partial-exit-qty-percent — teste strategy.exit(qty_percent=...) pour les sorties partielles de position. Si le moteur émet trop d’exécutions de sortie, c’est cette stratégie qui le détecte.
• Variantes de request.security — vérifient que les lectures sur une unité de temps supérieure se résolvent sur la bonne barre avec lookahead=barmerge.lookahead_off, avec et sans gaps.
• Groupes de sortie OCA — vérifient que, lorsqu’une sortie d’un groupe strategy.oca.reduce est exécutée, l’autre sortie du groupe est réduite de la quantité exécutée.
• Variantes de trailing stop — vérifient que le cliquet du trailing stop suit correctement le plus haut atteint, à travers les gaps et les exécutions d’ordres limites.
• Tests de méthodes UDT — vérifient que les méthodes des types définis par l’utilisateur de Pine v6 se compilent vers les bonnes opérations sur des struct C++.

La logique « si cette stratégie passe, la fonctionnalité X est couverte » guide explicitement ce que nous ajoutons à ce dossier. Quand un script communautaire révèle un nouveau cas limite, nous écrivons en général un reproducteur synthétique minimal et l’ajoutons à validation.

À quoi ressemblent vraiment les chiffres

Les 167 stratégies du corpus de l’époque tournaient toutes sur le même actif et la même unité de temps : ETHUSDT en barres de 15 minutes. C’est une contrainte délibérée : un OHLCV canonique unique rend les comparaisons entre stratégies pertinentes et retire de l’analyse de parité les facteurs propres à un actif.

Répartition du nombre de trades :

La stratégie médiane du corpus produisait 732 trades sur la fenêtre de backtest. Le minimum était de 13 (la stratégie greedy, très sélective), le maximum de 11 851. Cet étalement compte pour les tests de parité : sur une stratégie de 13 trades, une seule sortie mal placée représente 8 % d’erreur ; le même bug sur une stratégie de 5 000 trades se voit dans les métriques agrégées, même si la plupart des trades concordent.

Répartition des ratios de Sharpe :

La galerie calculait le Sharpe par trade (rendement moyen des trades en pourcentage, divisé par l’écart-type de ces rendements, sans annualisation), d’où des valeurs faibles. La plupart des stratégies du corpus y figuraient pour leur couverture des fonctionnalités Pine, pas pour leur rendement ajusté du risque. Le Sharpe médian sur les 167 stratégies était de 0,021. Sur les 167, 106 affichaient un rendement total positif sur la fenêtre de backtest et 61 un rendement négatif.

Nous affichions ces chiffres dans la galerie plutôt que de ne garder que les « bonnes » stratégies. Si vous cherchiez de l’inspiration, les colonnes rendement et Sharpe vous indiquaient où regarder. Si vous vérifiez la parité, les valeurs elles-mêmes importent peu : ce qui compte, c’est que PineForge et TradingView produisent les mêmes.

Ce que doit remplir chaque stratégie du corpus

Pour entrer dans le corpus, une stratégie doit remplir quatre conditions :

1. Compiler avec le codegen PineForge. Si elle ne compile pas, impossible de la tester. La barre est plus haute qu’il n’y paraît : certains scripts Pine communautaires chargent des bibliothèques via import, et le codegen ne compile ces scripts que si on lui fournit le code source de chaque bibliothèque.

2. Produire au moins un trade sur l’OHLCV canonique. Une stratégie qui compile mais ne déclenche jamais d’entrée n’a pas de liste de trades à comparer à quoi que ce soit.

3. Disposer d’un CSV de référence TradingView. Chaque stratégie du corpus a un export « List of Trades » de TradingView commité : tv_trades.csv ou, pour une stratégie d’autotest, un trades-<mode>.csv par mode. C’est la vérité terrain à laquelle on compare la sortie du moteur.

4. Avoir sa sortie moteur commitée à côté du code Pine. La galerie est servie à partir de ces sorties commitées. Rien n’y est généré à la volée : c’est l’instantané de ce que le moteur a produit le jour où la stratégie a été ajoutée ou mise à jour pour la dernière fois.

Pourquoi nous avons publié des agrégats, pas le code source

Jusqu’à la mi-mai 2026, la galerie publiait le nombre de trades, les rendements, les ratios de Sharpe et des sparklines, mais ni le code Pine ni les listes de trades brutes.

La raison qui vaut pour les scripts communautaires tient toujours : ils sont écrits par leurs auteurs, et nous n’avons pas l’autorisation de redistribuer leur code source. Les stratégies que nous avons écrites nous-mêmes ont depuis été publiées intégralement dans le corpus ouvert pineforge-corpus : pour chacune, le code Pine, le C++ généré, l’export TradingView et la liste de trades du moteur. La galerie renvoie vers l’ensemble de ces fichiers.

Ce que permet la galerie

La galerie s’adresse à trois publics :

Les quants indépendants en quête d’idées. Les stratégies varient assez en logique d’entrée, logique de sortie et type d’indicateur pour que parcourir la galerie donne un aperçu raisonnable de ce qui compile et tourne sur le moteur. Filtrez par catégorie et regardez les sparklines.

Les ingénieurs qui vérifient les annonces de parité. Pour vérifier une affirmation de parité, commencez par la galerie : chaque carte indique combien de ses trades sont identiques côté TradingView et côté PineForge, et les pages de stratégie montrent les deux listes de trades. La grille qui attribue les niveaux se trouve sur la page de méthodologie.

La référence de CI pour les releases du moteur. À l’époque, la campagne complète sur les 167 stratégies tournait sur les machines des mainteneurs ; la CI du moteur ne l’exécutait pas. Aujourd’hui, un workflow de parité relance chaque nuit, sur main, les 312 stratégies du corpus ouvert, et une pull request n’est fusionnée qu’avec un verdict de parité favorable issu de l’exécution complète lancée par les mainteneurs : toute modification de la sortie d’une stratégie est ainsi détectée avant d’être livrée.

Pour aller plus loin

• Parcourir la galerie : les 312 stratégies actuelles du corpus ouvert, filtrables par catégorie.
• Backtester depuis Claude ou Cursor : le serveur MCP hébergé gratuit, ou le serveur Docker local sur vos propres données OHLCV.
• Comment nous mesurons la parité : les résultats actuels et leurs sources.