Ce qu’est réellement une plateforme d’exécution

Quand on parle de modèles analytiques, de projections ou de simulations, beaucoup d’outils se concentrent sur une seule partie du problème.

Certains aident à préparer les données.
D’autres aident à construire une interface.
D’autres encore permettent de lancer un calcul précis dans un contexte précis.

Mais dans la pratique, le vrai besoin est souvent plus large.

Un modèle utile doit pouvoir être :

• décrit clairement
• exécutable de façon cohérente
• réutilisable dans plusieurs contextes
• intégrable à d’autres systèmes
• éditable sans repartir de zéro
• utilisable par différents profils selon leur rôle

C’est exactement là qu’intervient une plateforme d’exécution.

Une plateforme d’exécution, ce n’est pas seulement un accès à un moteur de calcul

Un moteur d’exécution seul ne suffit pas.

Il peut être puissant, rapide, même très performant. Mais si tout ce qu’il faut autour pour l’exécuter reste à reconstruire à chaque fois, le coût global reste élevé.

Une plateforme d’exécution va plus loin.

Elle fournit une base commune pour :

• décrire les modèles
• les exécuter
• y accéder de plusieurs façons
• garder la même logique d’un contexte à l’autre

Autrement dit, elle ne s’occupe pas seulement du calcul.

Elle s’occupe aussi de la manière dont ce calcul devient réellement utilisable.

Pourquoi cela change beaucoup de choses

Sans cette cohérence intrinsèque, un même besoin finit souvent par être recréé plusieurs fois :

• dans un fichier
• dans un script
• dans une interface
• dans un backend
• dans une logique d’intégration

Et chaque fois, on ajoute de la complexité.

Avec une plateforme d’exécution, l’objectif est différent :

décrire la logique une fois, puis l’utiliser dans plusieurs contextes sans redévelopper la fondation à chaque fois.

C’est ce déplacement qui change l’économie du problème.

Ce que Subspace apporte

Subspace est conçu dans cette logique.

L’idée n’est pas seulement de fournir un calcul plus rapide.

L’idée est de fournir une infrastructure d’exécution pour les modèles et les projections analytiques.

Et qui est consommable comme un service.

Cette infrastructure peut ensuite être utilisée :

• dans le portail
• via API
• avec un SDK
• dans un produit
• dans un workflow interne

Le point important n’est pas seulement qu’il y ait plusieurs moyens d’y accéder.

Le point important est que ces accès reposent sur la même logique d’exécution.

Ce que cela permet

Quand une même base sert à plusieurs usages, plusieurs gains apparaissent :

• moins de redéveloppement
• moins de duplication
• plus de cohérence
• plus de réutilisation
• plus de clarté sur ce qui est exécuté
• plus de facilité pour faire évoluer un modèle

Le gain ne vient donc pas seulement de la vitesse.

Il vient aussi du fait que l’exécution cesse d’être une fondation à reconstruire sans cesse.

Du portail au modèle exécutable

Les images présentées ici montrent le même modèle sous plusieurs angles dans le portail Subspace.

On y voit différentes vues du produit, mais il ne s’agit pas de logiques séparées.

Ces vues correspondent à différentes façons d’interagir avec une même exécution.

Le portail expose le même modèle que celui qu’on peut ensuite utiliser dans un script Python, dans une application TypeScript ou via l’API HTTP.

Vue schéma : dépendances entre variables

Résultats générés

Distributions

Modèle côté API et réponse JSON

Les captures ci-dessus correspondent au modèle Capital projection : 1000 scénarios, 12 pas, un taux uniforme par scénario, puis des variables dérivées comme capital et profit.

Le JSON ci-dessous est le SP Model équivalent.

{
  "steps": 12,
  "scenarios": 1000,
  "variables": [
    {
      "per": "scenario",
      "dist": "uniform",
      "name": "taux",
      "params": {
        "max": 0.07,
        "min": 0.03
      }
    },
    {
      "init": 1000,
      "name": "capital",
      "formula": "capital[t-1] * (1 + taux)"
    },
    {
      "init": 0,
      "name": "profit",
      "formula": "capital[t] - capital[0]"
    }
  ]
}

Ce point est central.

Ce JSON n’est pas une représentation secondaire ou décorative du modèle.

C’est la description même du modèle.

C'est via cette base que le moteur de calcul de Subspace interpète le modèle à exécuter, peu importe depuis quel mode d'accès.

Une même logique, plusieurs points d’accès

Une fois le modèle décrit, il peut être exécuté de plusieurs façons selon le contexte.

Depuis le portail, on le visualise et on le lance dans une interface.

Depuis Python, on peut l’intégrer à un script analytique.

Depuis TypeScript, on peut l’utiliser dans un produit web client ou une application administrative interne.

Et via l’API HTTP, on peut l’appeler depuis n’importe quel système capable d’envoyer une requête.

Les extraits ci-dessous ne représentent pas plusieurs implémentations différentes.

Ils montrent au contraire la même logique d’exécution, exposée à travers plusieurs points d’accès.

Exemple Python (SDK)

from subspacecomputing import BSCE
 
client = BSCE(api_key="be_live_...", team_id="uuid-equipe-optionnel")
 
spec = {
    "scenarios": 1000,
    "steps": 12,
    "variables": [
        {
            "name": "taux",
            "dist": "uniform",
            "params": {"min": 0.03, "max": 0.07},
            "per": "scenario",
        },
        {
            "name": "capital",
            "init": 1000.0,
            "formula": "capital[t-1] * (1 + taux)",
        },
        {
            "name": "profit",
            "init": 0.0,
            "formula": "capital[t] - capital[0]",
        },
    ],
}
 
result = client.simulate(spec)
print(result["last_mean"]["capital"], result["last_mean"]["profit"])

Exemple TypeScript (SDK)

import { BSCE } from '@beausoft/subspace';
 
const client = new BSCE('be_live_...', undefined, 'uuid-equipe-optionnel');
 
const spec = {
  scenarios: 1000,
  steps: 12,
  variables: [
    {
      name: 'taux',
      dist: 'uniform',
      params: { min: 0.03, max: 0.07 },
      per: 'scenario',
    },
    {
      name: 'capital',
      init: 1000.0,
      formula: 'capital[t-1] * (1 + taux)',
    },
    {
      name: 'profit',
      init: 0.0,
      formula: 'capital[t] - capital[0]',
    },
  ],
};
 
const result = await client.simulate(spec);
console.log(result.last_mean.capital, result.last_mean.profit);

Exemple API (HTTP)

curl -sS -X POST "https://api.subspacecomputing.com/simulate" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: be_live_..." \
  -H "X-Team-Id: 00000000-0000-4000-8000-0000000000b2" \
  -d '{
    "scenarios": 1000,
    "steps": 12,
    "variables": [
      {"name": "taux", "dist": "uniform", "params": {"min": 0.03, "max": 0.07}, "per": "scenario"},
      {"name": "capital", "init": 1000, "formula": "capital[t-1] * (1 + taux)"},
      {"name": "profit", "init": 0, "formula": "capital[t] - capital[0]"}
    ]
  }'

Que l’on passe par le portail, le SDK Python, le SDK TypeScript ou l’API HTTP, le point essentiel reste le même :

on ne réécrit pas une logique différente selon le point d’accès.
On exécute le même modèle à travers des interfaces différentes.

Pourquoi cela compte vraiment

Ce point n’est pas seulement architectural.

Il est aussi très concret pour une organisation.

Quand plusieurs usages reposent sur une logique commune, il devient plus simple de faire évoluer le système sans multiplier les versions, les ajustements parallèles et les écarts entre implémentations.

Les intégrations sont plus propres, la maintenance devient plus saine, et l’organisation passe moins de temps à recoller plusieurs variantes d’une même logique.

Autrement dit, le partage du même moteur n’est pas seulement une élégance technique.

C’est aussi une façon plus intelligente de faire vivre des modèles analytiques.

Conclusion

Une plateforme d’exécution n’est pas seulement une interface pour lancer un calcul.

C’est une infrastructure d’exécution commune qui permet à un même modèle d’être décrit, exécuté, visualisé, réutilisé et intégré sans devoir être reconstruit selon le contexte.

C’est précisément ce que montrent ici le portail, le SP Model et les extraits Python, TypeScript et API : plusieurs façons d’accéder à une même logique d’exécution.

Accessible comme un service.

C’est exactement dans cette logique que Subspace s’inscrit.