Navigateur, Worker ou API ? La frontière de calcul d'Option Model Lab
Comment les mesures, et non le prestige d'un modèle, ont déterminé les calculs locaux et la seule calibration qui traverse le réseau.
Au début d’Option Model Lab, tous les calculs tournaient dans le navigateur. C’était une contrainte volontaire : une application statique est simple à ouvrir et à héberger, sans être condamnée à rester passive.
L’ajout ultérieur d’un backend a posé une vraie question : quels calculs fallait-il y déplacer ? « Les modèles compliqués » semble être une réponse raisonnable, mais ce n’est pas une règle d’architecture exploitable.
J’ai mesuré le travail réellement affiché
J’ai benchmarké les fixtures utilisées par l’interface : un contrat, un smile affiché, une petite calibration, une comparaison. Sur la machine de référence, les médianes allaient de quelques microsecondes pour Black–Scholes et SABR à environ 174 ms pour la calibration Heston bornée sur 15 quotes.
Ces chiffres comparent des choix de développement ; ce ne sont pas des promesses de latence. Ils servent à distinguer trois cas :
- le calcul assez léger pour le thread principal ;
- le calcul local et déterministe qui peut interrompre l’interaction ;
- l’opération bornée, déclenchée par l’utilisateur et assez coûteuse pour justifier le réseau.
Le résultat important est la quantité de calculs qui ne doivent pas bouger.
Le pricing reste près des contrôles
Pricing et Greeks Black–Scholes, inversion de volatilité implicite, prix et smiles Heston affichés, Merton, SABR, reconstruction Local Vol actuelle et comparaison de deux modèles restent locaux.
Ce choix évite un aller-retour réseau à chaque déplacement de slider. L’interface reste aussi utilisable sans l’API de production. Les modules quantitatifs TypeScript ne dépendent pas de React : ils se testent directement sans monter l’interface.
La sophistication mathématique n’est pas un critère de déploiement. Le pricer Heston actuel est assez rapide pour une manipulation directe ; l’envoyer au serveur ralentirait le produit.
Le Worker protège l’interface
La calibration Heston était déjà l’exception. Elle est déterministe et locale, mais l’ajustement borné peut bloquer le thread principal assez longtemps pour être perceptible. Son déplacement dans un Web Worker a conservé l’architecture statique tout en gardant les contrôles réactifs.
Je n’ai pas transformé ce Worker en framework universel de calibration. Merton et SABR ont des procédures différentes, plus petites, qui restent plus lisibles sous forme d’implémentations concrètes.
L’API ne prend en charge qu’une opération bornée
Le premier périmètre distant est étroit : POST /api/v1/heston/calibrate.
Le service valide le nombre de quotes et d’itérations, limite le nombre de calibrations simultanées et ne stocke aucune donnée utilisateur. Une erreur réseau, une erreur serveur ou un service saturé ne bloque pas le laboratoire : l’interface indique le chemin d’exécution puis utilise le Worker numériquement aligné.
Cette frontière donne un vrai rôle au backend sans rendre le développement local dépendant du DNS de production. Elle réduit aussi le risque d’épuisement des ressources publiques. Pour un endpoint numérique coûteux, être « stateless » ne suffit pas : les entrées et la concurrence doivent être bornées.
La parité numérique fait partie du contrat
Dès que TypeScript et Python couvrent le même comportement Heston, un statut HTTP 200 ne suffit pas. Des fixtures partagées et des tolérances explicites vérifient leur accord. Les entrées financières invalides sont signalées, jamais corrigées silencieusement : un graphique pratique ne justifie pas de masquer une erreur de domaine.
La règle que je conserve
La règle finale tient en une phrase :
Je place un calcul selon son coût mesuré pour l’utilisateur, pas selon la sophistication apparente de ses mathématiques.
Une surface à l’échelle du marché, un Monte Carlo plus large ou une calibration plus ambitieuse demanderont un nouveau benchmark. Ils n’hériteront pas automatiquement de la décision prise pour Heston.