Licences binaire compilé pour stratégies : l’espace de conception

Les créateurs de stratégies veulent monétiser sans livrer le code source. Les acheteurs veulent backtester sur leurs propies données et exécuter chez leur propre courtier. Ces deux exigences sont réellement en tension, et la plupart des solutions actuelles la résolvent mal. Cet article décrit l’espace de conception que nous avons exploré avant d’ancrer le marché PineForge sur des licences portant sur un binaire compilé.

Le problème en termes simples

Un créateur a construit quelque chose qui fonctionne. Il a passé des mois à peaufiner les paramètres, à corriger les cas limites, à valider hors échantillon. Il veut le vendre. L’acheteur veut l’exécuter sur ses données, vérifier que le backtest correspond aux affirmations du créateur et le brancher sur sa propre chaîne d’exécution.

Dès que le créateur remet le code source, la monétisation se termine. L’acheteur peut l’exécuter indéfiniment, le modifier librement et le revendre. Le créateur n’a capturé qu’une seule vente. Chaque acheteur suivant est un client potentiel perdu.

Dès que le créateur retient le code source, l’acheteur perd la capacité de vérifier, d’ajuster ou de faire confiance à la stratégie. Il s’abonne à une boîte noire. Si le serveur du créateur tombe, le trading s’arrête.

Deux solutions courantes tentent de naviguer ce dilemme. Toutes deux ont des modes d’échec bien documentés.

Schéma 1 : vendre le code source

Le créateur vend le script Pine directement. Un achat unique donne le fichier .pine.

Le bénéfice pour l’acheteur est réel : accès complet, vérifiabilité complète, contrôle total. Il peut backtester sur n’importe quelles données, ajuster les paramètres et exécuter indépendamment du vendeur pour toujours.

L’inconvénient pour le vendeur est tout aussi réel. Une fois le code transféré, il n’a plus de levier durable. La protection contre la piraterie tient autant que la bonne volonté de l’acheteur. La stratégie peut être relistée ailleurs, modifiée et vendue comme dérivé, ou simplement partagée. Le chiffre d’affaires est plafonné par le nombre d’acheteurs honnêtes du premier achat.

Ce modèle convient aux créateurs qui privilégient la simplicité aux revenus récurrents. Il ne convient pas à ceux dont les stratégies sont assez précieuses pour mériter une protection sur plusieurs années.

Schéma 2 : vendre des signaux

Le créateur exécute lui-même la stratégie et publie des signaux — entrée, sortie et taille de position — dans un flux consommé par les abonnés. Le code ne quitte jamais son contrôle.

Le bénéfice pour le vendeur : protection totale du code, revenus d’abonnement en continu, aucune transaction unique qui transfère toute la valeur.

L’inconvénient pour l’acheteur est sérieux. Il ne peut pas backtester la stratégie sur ses propies données. Il doit croire la performance historique déclarée par le créateur. Il dépend entièrement de l’infrastructure du créateur — vacances, panne de serveur ou fermeture du service, et l’acheteur ne garde rien. Il ne peut pas non plus ajuster les paramètres ; il reçoit ce que le créateur a configuré.

Les services de signaux conviennent aux acheteurs sans capacité technique pour exécuter eux-mêmes les stratégies. Pour les acheteurs techniques qui veulent comprendre ce qu’ils exécutent et le vérifier indépendamment, le modèle est un impasse.

Schéma 3 : vendre le binaire compilé

Le troisième schéma est celui sur lequel repose le marketplace PineForge. La stratégie Pine compile en bibliothèque partagée (.so sous Linux, .dylib sous macOS). Le créateur distribue le binaire, pas le code. L’acheteur exécute le binaire contre ses propres données OHLCV sur sa machine, via le runtime open source PineForge.

Cela traite les deux côtés de la tension :

Pour le créateur : le code ne quitte pas sa machine. Le binaire est compilé depuis son script Pine, mais reconvertir un .so compilé en Pine lisible demande un effort considérable — et même ainsi le résultat est de l’assembleur, pas du Pine idiomatique. La logique cœur de la stratégie est matériellement protégée.

Pour l’acheteur : le backtest tourne en local sur ses données. L’exécution utilise son intégration courtier. Le runtime open source est auditable — un acheteur soucieux de la sécurité peut lire le code qui fait tourner son argent, même s’il ne peut pas lire la stratégie elle-même. Le backtest ne dépend pas du serveur du vendeur.

Ce schéma n’est pas nouveau pour PineForge. L’écosystème MetaTrader 4/5 fonctionne ainsi depuis le lancement de MQL5 Market vers 2012. Les stratégies MetaTrader compilent en binaires .ex5, distribués verrouillés par compte et limités dans le temps via le marketplace. Les acheteurs backtestent localement dans le testeur de stratégies MetaTrader ; le code reste chez le développeur. C’est un modèle éprouvé à grande échelle.

Nous appliquons le même playbook à Pine, avec deux ajouts : une granularité accrue des paramètres de licence (ci-dessous), et un runtime open source pour auditer la partie qui exécute les trades.

Les dimensions de licence

Un binaire compilé sans cadre de licence n’est qu’un fichier copiable. La couche de licence fait tenir le modèle économique.

Les outils vendeur PineForge exposent six dimensions de licence :

Limitée dans le temps. La licence a une date d’expiration — jours, semaines ou mois après l’achat. À expiration, le binaire cesse d’exécuter les stratégies. L’acheteur peut renouveler. Le vendeur obtient des revenus récurrents. C’est la dimension la plus courante ; presque toute stratégie du marketplace l’emploiera.

Liée à la machine. La licence est attachée à une empreinte matérielle. L’acheteur peut exécuter la stratégie sur la machine enregistrée, pas sur une seconde machine ni une instance cloud. Cela limite la valeur du partage du binaire — la machine du destinataire n’aura pas de licence valide. Les vendeurs plus préoccupés par la piraterie à grande échelle que par le partage occasionnel peuvent l’activer.

Liée au courtier. La licence précise quelles intégrations courtier sont autorisées pour l’exécution. Un vendeur partenaire d’APIs spécifiques peut limiter l’exécution à ces intégrations, empêchant l’usage sur un lieu d’exécution non supporté ou indésirable.

Liée au symbole. La licence restreint les tickers que la stratégie peut trader. Un créateur qui a construit et validé sa stratégie sur BTC/USDT peut distribuer une licence qui n’autorise que ce symbole. Cela évite qu’un acheteur applique une strategie optimisée pour un actif à un actif totalement différent, obtienne des résultats inattendus et blâme le créateur.

Plage d’inputs bornée. L’acheteur peut ajuster les paramètres, mais seulement dans les plages que le vendeur autorise. Une stratégie avec une fenêtre de lookback peut autoriser des valeurs entre 10 et 50 barres, mais pas en dessous de 10 (où le créateur sait qu’il y a eu un surapprentissage fort) ni au-dessus de 50 (où cela devient dénué de sens). Le vendeur publie les plages ; le runtime les impose.

Révocable. Le serveur de licences peut répondre 403 au prochain contrôle périodique, et le binaire cesse alors d’exécuter. Si un acheteur viole les conditions — partage du binaire, exécution sur matériel non autorisé — le créateur peut révoquer sans remboursement ni long processus juridique. La révocation est l’option ultime ; les vendeurs ne devraient l’utiliser que pour des violations claires.

Ce que nous ne faisons pas délibérément

Pas de théâtre d’obfuscation façon DRM. Le .so est un vrai binaire compilé. Avec assez de temps et les bons outils, un ingénieur compétent peut en reverse engineer la logique. Nous ne prétendons pas le contraire. La licence est le contrat, pas le format du binaire. La protection vient des termes acceptés par l’acheteur et de l’application par le runtime, pas de l’impossibilité du désassemblage. Prétendre que le binaire est incassable serait malhonnête.

Pas d’appel serveur à chaque backtest. La vérification de licence est périodique, pas par appel. Le runtime met en cache une licence valide localement et interroge le serveur selon un calendrier (configurable par licence, par défaut quotidien). Les backtests fonctionnent hors ligne pendant la fenêtre de licence. Nous ne téléphonons pas à la maison à chaque barre. Cela rendrait les backtests dépendants du réseau et ajouterait de la latence sans gain de sécurité réel — un attaquant qui intercepte un contrôle peut en intercepter cent.

Pas de partage de revenus surprise. Le taux de prélèvement du marketplace est un pourcentage fixe publié avant le lancement. Les vendeurs sur la liste d’attente connaissent les conditions avant de lister. Nous avons vu des marketplaces qui ne révèlent leur commission qu’après mise en ligne du produit — nous considérons cela comme de mauvaise foi et ne le ferons pas.

Questions ouvertes sur lesquelles nous travaillons encore

Compromis de clé de licence. Si la machine d’un acheteur est compromise et que sa clé est extraite, que se passe-t-il ? Options : (a) révoquer et réémettre pour l’acheteur légitime, avec perturbation ; (b) maintenir une rotation de clés par acheteur où chaque instance de machine a une clé dérivée distincte, de sorte qu’un compromis sur une machine ne compromet pas tous les acheteurs. Nous penchons pour (b), mais l’implémentation impose une gestion des clés non triviale.

Valeurs par défaut définies par le vendeur en plus des plages. La dimension de plage d’inputs permet de publier les bornes de chaque paramètre. Les vendeurs devraient-ils aussi pouvoir publier des valeurs par défaut — la valeur initiale que l’acheteur voit à la première configuration ? Probablement oui : un vendeur qui sait que sa stratégie fonctionne mieux avec un lookback de 20 barres ne devrait pas forcer les acheteurs à le découvrir par essais et erreurs. Les défauts seraient indicatifs, pas imposés.

Rapports de « demo backtest » publiés par le vendeur. Avant d’acheter, les acheteurs devraient voir une preuve que la stratégie fonctionne — pas seulement les affirmations du vendeur. Notre plan actuel est de permettre des galeries de rapports de backtest (même schéma que la galerie sur /gallery) avec leurs données et fenêtre OHLCV. Le rapport serait vérifié comme produit par le moteur PineForge sur les entrées déclarées. Les acheteurs voient de vraies listes de trades, de vrais ratios de Sharpe, de vraies sparklines — pas une capture marketing. C’est la version honnête de « voyez avant d’acheter ».

L’alignement open-core

Une inquiétude avec les marketplaces de binaires compilés est que la sécurité de l’argent de l’acheteur repose entièrement sur l’exécuteur du binaire — qui, dans beaucoup d’implémentations, est une boîte noire propriétaire. Si vous exécutez un fichier .ex5 dans MetaTrader, vous faites confiance au runtime de MetaQuotes et à leur assurance qu’il n’exécutera pas de comportement non divulgué.

Le runtime PineForge est sous licence Apache-2.0 et disponible publiquement sur ghcr.io/pineforge-4pass/pineforge-engine:latest. Le codegen (la partie qui compile Pine en C++) est propriétaire — c’est là que vit le business. Mais l’exécuteur — le code qui fait réellement tourner le binaire contre votre OHLCV et produit les listes de trades — est open source.

Un acheteur soucieux de la sécurité peut donc auditer l’exécuteur avant de lui confier son backtesting. Il ne peut pas auditer le code de la stratégie (c’est le principe), mais il peut auditer le conteneur qui l’exécute. La séparation est volontaire : garder ouvert ce qui touche l’argent réel ; garder fermé ce qui constitue le fossé compétitif.

Calendrier du marketplace

La bêta démarre au quatrième trimestre 2026 avec onboarding manuel des vendeurs — une petite cohorte de créateurs validés, des fiches stratégie revues par l’équipe et un parcours d’achat simplifié pour les acheteurs. Nous ferons tourner la bêta sur de vraies transactions avec un catalogue limité pour attraper les problèmes d’intégration avant la montée en charge.

Le marketplace entièrement en libre-service ouvre en 2027. Les vendeurs pourront alors lister de façon autonome, définir leurs dimensions de licence, publier des rapports de demo backtest et gérer leur catalogue sans intervention de l’équipe.

Ce sont des dates honnêtes, pas aspirantes. Le moteur et le codegen existent déjà. Le serveur de licences, le tableau de bord vendeur et le flux d’achat acheteur sont des chantiers 2026.

Pour aller plus loin

• Rejoindre la liste d’attente vendeurs — si vous construisez des stratégies que vous aimeriez lister, inscrivez-vous et nous vous contacterons à l’ouverture de l’onboarding bêta.
• Essayer le runtime aujourd’hui — backtest_pine via le serveur MCP est le même exécuteur que les stratégies du marketplace utiliseront. Si votre stratégie fonctionne correctement dans le flux MCP, elle fonctionnera correctement sur le marketplace.
• Obtenir un accès anticipé — le niveau gratuit donne 100 transpilations par mois pour construire et valider des stratégies avant le lancement du marketplace.