Aller au contenu
PineForge

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

8 min de lecture

Vendre une stratégie sous forme de code source est risqué. La vendre comme service hébergé est lourd. La vendre comme binaire compilé, avec des bornes de licence définies par le vendeur, est la voie autour de laquelle est conçue la marketplace prévue par PineForge ; voici l’exploration de conception qui nous y a menés.

État au 2026-09-30 : ce billet est une exploration de conception. La marketplace, le serveur de licences et les outils vendeur qu’il décrit sont prévus mais pas construits, et aucune date de sortie n’est fixée. Le moteur et le transpileur sur lesquels elle reposerait existent déjà.

Les créateurs de stratégies veulent monétiser leur travail sans céder leur code source. Les acheteurs veulent backtester sur leurs propres données et exécuter chez leur propre courtier. Ces deux exigences sont réellement en tension, et la plupart des solutions actuelles tranchent mal. Ce billet décrit l’espace de conception que nous avons exploré avant de retenir la licence sur binaire compilé comme fondation de la marketplace PineForge.

Le problème en termes simples

Un créateur de stratégie a construit quelque chose qui fonctionne. Il a passé des mois à régler les paramètres, à corriger les cas limites, à valider hors échantillon. Il veut la vendre. L’acheteur, lui, veut la faire tourner sur ses propres données, vérifier que le backtest donne ce qu’annonce le créateur, et la brancher sur sa propre chaîne d’exécution.

Dès que le créateur remet le code source, la monétisation s’arrête. L’acheteur peut l’exécuter indéfiniment, le modifier librement et le revendre à d’autres. Le créateur n’a réalisé qu’une seule vente. Chaque acheteur suivant est un client potentiel perdu.

Dès que le créateur garde le code source pour lui, l’acheteur perd la possibilité de vérifier la stratégie, de l’ajuster ou de s’y fier. Il s’abonne à une boîte noire. Si le serveur du créateur tombe, son trading s’arrête.

Deux solutions courantes tentent de s’en sortir. Toutes deux ont des modes d’échec bien documentés.

Approche 1 : vendre le code source

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

L’avantage 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 la stratégie indépendamment du vendeur, pour toujours.

L’inconvénient pour le vendeur est tout aussi réel. Une fois le code transféré, le vendeur n’a plus aucun levier. La protection contre le piratage ne vaut que ce que vaut la bonne foi de l’acheteur. La stratégie peut être remise en vente sur d’autres plateformes, modifiée et vendue comme œuvre dérivée, ou tout simplement partagée librement. Le chiffre d’affaires plafonne au nombre d’acheteurs honnêtes de première main.

Ce modèle convient aux créateurs qui préfèrent la simplicité à des revenus récurrents. Il ne convient pas à ceux dont les stratégies ont assez de valeur pour qu’ils veuillent les protéger sur plusieurs années.

Approche 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 que consomment les abonnés. Le code source ne quitte jamais son contrôle.

L’avantage pour le vendeur : protection totale du code source, revenus d’abonnement récurrents, et 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 propres données. Il doit croire le créateur sur parole quant aux performances historiques annoncées. Il dépend entièrement de l’infrastructure du créateur : si celui-ci part en vacances, subit une panne de serveur ou décide d’arrêter, l’acheteur n’a plus 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 qui n’ont pas les moyens techniques d’exécuter eux-mêmes des stratégies. Pour les acheteurs techniques qui veulent comprendre ce qu’ils exécutent et le vérifier par eux-mêmes, ce modèle est une impasse.

Approche 3 : vendre le binaire compilé

La troisième approche est celle autour de laquelle est conçue la marketplace prévue par PineForge. La stratégie Pine se compile en bibliothèque partagée (.so sous Linux, .dylib sous macOS). Le créateur distribue le binaire, pas le code source. L’acheteur exécute le binaire sur ses propres données OHLCV, sur sa propre machine, via le runtime open source de PineForge.

Cette approche répond aux deux côtés de la tension :

Pour le créateur : le code source ne quitte jamais sa machine. Le binaire est compilé à partir de son script Pine, mais remonter d’un .so compilé à du Pine lisible demande un effort considérable ; et même dans ce cas, on obtient du code de niveau assembleur, pas du Pine idiomatique. La logique centrale de la stratégie est protégée de façon concrète.

Pour l’acheteur : le backtest tourne en local, sur ses propres données. L’exécution passe par sa propre intégration courtier. Le runtime open source est auditable : un acheteur soucieux de 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 lui-même ne dépend en rien du serveur du vendeur.

L’approche n’est pas une invention de PineForge. L’écosystème MetaTrader fonctionne ainsi depuis que MetaQuotes a ouvert le MQL5 Market, en 2011. Les stratégies MetaTrader se compilent en binaires .ex4 ou .ex5 ; le Market verrouille chaque achat sur l’ordinateur de l’acheteur, avec un nombre d’activations fixé par le vendeur, et les vendeurs peuvent aussi proposer un produit à la location. Les acheteurs backtestent en local dans le testeur de stratégies de MetaTrader ; le code source reste chez le développeur. C’est un modèle éprouvé.

Nous appliquons la même recette à Pine, avec deux ajouts : des réglages de licence plus fins (voir plus bas), et un runtime open source, pour que chacun puisse auditer la partie qui exécute ses trades.

Les dimensions de licence

Un binaire compilé sans cadre de licence n’est qu’un fichier que n’importe qui peut copier. C’est la couche de licence qui fait fonctionner le modèle économique.

La conception prévoit six dimensions de licence :

Limitée dans le temps. La licence a une date d’expiration : quelques jours, semaines ou mois après l’achat. À l’expiration, le binaire cesse d’exécuter les stratégies. L’acheteur peut renouveler. Le vendeur perçoit des revenus récurrents. C’est la dimension la plus courante ; presque toutes les stratégies de la marketplace l’utiliseront.

Liée à une machine. La licence est attachée à une empreinte matérielle. L’acheteur peut exécuter la stratégie sur la machine qu’il a enregistrée, mais pas sur une deuxième machine ni sur une instance cloud. Cela réduit l’intérêt de partager le binaire : la machine du destinataire n’aura pas de licence valide. Les vendeurs plus inquiets du piratage à grande échelle que du partage occasionnel peuvent l’activer.

Liée à un courtier. La licence précise avec quelles intégrations courtier la stratégie a le droit de s’exécuter. Un vendeur partenaire de certaines API de courtiers peut limiter l’exécution à ces intégrations, et empêcher ainsi l’utilisation de la stratégie sur une plateforme d’exécution non prise en charge ou indésirable.

Liée à un symbole. La licence restreint les symboles 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 stratégie optimisée pour un actif à un actif complètement différent, obtienne des résultats inattendus… et s’en prenne au créateur.

Bornée sur les inputs. L’acheteur peut ajuster les paramètres de la stratégie, mais seulement dans les plages autorisées par le vendeur. Une stratégie dotée d’un paramètre de fenêtre de lookback peut laisser l’acheteur le régler entre 10 et 50 barres, mais pas en dessous de 10 (où le créateur sait qu’elle surapprend fortement) ni au-dessus de 50 (où elle n’a plus de sens). Le vendeur publie les plages ; le runtime les fait respecter.

Révocable. Le serveur de licences peut renvoyer un 403 lors du contrôle périodique suivant ; le binaire cesse alors de s’exécuter. Si un acheteur enfreint les conditions (en partageant le binaire, en l’exécutant sur du matériel non autorisé), le créateur peut révoquer la licence sans rembourser ni passer par une procédure judiciaire. La révocation est l’arme ultime ; les vendeurs ne devraient y recourir qu’en cas de violation manifeste.

Ce que nous choisissons de ne pas faire

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 reconstituer la logique par rétro-ingénierie. Nous ne prétendons pas le contraire. C’est la licence qui fait office de contrat, pas le format du binaire. La protection vient des conditions acceptées par l’acheteur et de l’application de la licence par le runtime, pas d’une impossibilité de désassembler. Prétendre que le binaire est inviolable serait malhonnête.

Pas d’appel au serveur à chaque backtest. La vérification de licence est périodique, pas faite à chaque appel. Le runtime garde en cache local une licence valide et interroge le serveur de licences selon un calendrier (configurable par licence, quotidien par défaut). Les backtests fonctionnent hors ligne pendant la période de validité de la licence. Nous n’appelons pas le serveur à chaque calcul de barre : les backtests dépendraient alors de la disponibilité du réseau, et on ajouterait de la latence sans réel bénéfice de sécurité. Un attaquant capable d’intercepter un contrôle de licence peut en intercepter cent.

Pas de partage de revenus surprise. La commission de la marketplace est un pourcentage fixe, publié avant le lancement. Les vendeurs inscrits sur la liste d’attente connaissent les conditions avant de mettre en vente. Nous avons vu des marketplaces ne dévoiler leur grille de commissions qu’une fois le produit en ligne ; nous considérons que c’est de la mauvaise foi, et nous ne le ferons pas.

Les questions encore ouvertes

Compromission d’une clé de licence. Si la machine d’un acheteur est compromise et que sa clé de licence est extraite, que se passe-t-il ? Deux options : (a) révoquer puis réémettre une clé pour l’acheteur légitime, au prix d’une interruption ; (b) mettre en place une rotation de clés par acheteur, où chaque instance de machine possède une clé dérivée distincte, de sorte que la compromission d’une machine ne compromette pas tous les acheteurs. Nous penchons pour (b), mais sa mise en œuvre impose une gestion des clés non triviale.

Des valeurs par défaut définies par le vendeur, en plus des plages. La dimension de bornage des inputs permet aux vendeurs de publier les bornes de chaque paramètre. Devraient-ils aussi pouvoir publier des valeurs par défaut, c’est-à-dire la valeur de départ que voit l’acheteur quand il configure la stratégie pour la première fois ? Probablement : un vendeur qui sait que sa stratégie donne le meilleur d’elle-même avec un lookback de 20 barres ne devrait pas obliger les acheteurs à le découvrir par tâtonnements. Ces valeurs par défaut seraient indicatives, pas imposées.

Des rapports de « backtest de démonstration » publiés par le vendeur. Avant d’acheter, les acheteurs devraient pouvoir constater que la stratégie fonctionne, et pas seulement lire ce qu’en dit le vendeur. Notre plan actuel : permettre aux vendeurs de publier un rapport de backtest au format de la galerie (même schéma que la galerie sur /gallery), avec leurs propres données et leur propre fenêtre OHLCV. On vérifierait que le rapport a bien été 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 d’écran marketing. C’est la version honnête de « voyez avant d’acheter ».

La logique open-core

Une inquiétude revient avec les marketplaces de binaires compilés : la sécurité de l’argent de l’acheteur dépend entièrement de l’exécuteur du binaire, qui, dans la plupart des 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 à son engagement de n’avoir aucun comportement non déclaré.

Le moteur de PineForge est public et sous licence Apache-2.0 (pineforge-engine ; l’image Docker, qui embarque le moteur et le transpileur, est ghcr.io/pineforge-4pass/pineforge-release). Le transpileur (la partie qui compile le Pine en C++) est gratuit pour le trading personnel ; un usage commercial nécessite une licence. L’exécuteur, c’est-à-dire le code qui fait réellement tourner le binaire compilé sur votre OHLCV et produit les listes de trades, est open source.

Un acheteur soucieux de sécurité peut donc auditer l’exécuteur avant de lui confier ses backtests. Il ne peut pas auditer le code source de la stratégie (c’est tout le principe), mais il peut auditer le code qui l’exécute. Ce partage est délibéré : garder ouverte la partie qui exécute la stratégie, et soumettre le transpileur à licence pour un usage commercial.

Où en est la marketplace

Aucune date n’est fixée. Le moteur et le transpileur existent aujourd’hui ; le serveur de licences, le tableau de bord vendeur et le parcours d’achat côté acheteur, non.

Le plan : d’abord une bêta, avec un onboarding manuel des vendeurs (une petite cohorte de créateurs sélectionnés, des fiches relues par l’équipe et un catalogue limité, pour repérer les problèmes d’intégration avant de passer à l’échelle). Viendrait ensuite une marketplace en libre-service, où les vendeurs publieraient leurs fiches en autonomie, fixeraient leurs propres dimensions de licence, publieraient des rapports de backtest de démonstration et géreraient leur catalogue sans intervention de l’équipe.

Pour aller plus loin