Pourquoi portail, API et SDK partagent le même moteur

Quand un produit offre plusieurs façons d’y accéder, il est facile de croire qu’il s’agit simplement de plusieurs interfaces posées côte à côte.

Un portail pour les utilisateurs.
Une API pour les développeurs.
Un SDK pour les intégrations.

Vu de l’extérieur, cela peut ressembler à trois portes différentes vers trois expériences différentes.

Mais dans beaucoup de cas, le vrai problème commence justement là.

Parce que lorsque plusieurs interfaces reposent sur des logiques différentes, les coûts réapparaissent vite :

• duplication
• divergence
• maintenance plus lourde
• résultats moins cohérents
• intégrations plus fragiles
• évolution plus difficile

Autrement dit, multiplier les points d’accès ne crée pas forcément de la cohérence.

Cela peut au contraire multiplier la fragmentation.

Le vrai enjeu n’est pas d’avoir plusieurs interfaces

Le vrai enjeu est d’avoir plusieurs façons d’accéder à la même logique, sans devoir la redévelopper selon le contexte.

Dans beaucoup d’environnements, une même capacité finit par exister sous plusieurs formes :

• une version visible dans l’interface
• une version exposée par API
• une version adaptée à un script
• parfois une autre version reconstruite dans un système voisin

Et à partir du moment où ces variantes se multiplient, le coût augmente.

Il faut maintenir.
Il faut vérifier.
Il faut tester plusieurs chemins.
Il faut réconcilier les résultats.
Il faut s’assurer que tout évolue ensemble.

Le problème n’est donc pas seulement d’ouvrir plusieurs accès.

Le problème est de garder une seule vérité d’exécution derrière ces accès.

Une autre approche

Une architecture plus solide consiste à inverser la logique.

Au lieu de penser :

• un portail avec sa logique
• une API avec sa logique
• un SDK avec sa logique

on pense :

• un moteur commun
• plusieurs modes d’accès au même moteur

Cette différence paraît simple.

Mais elle change profondément la manière dont le système évolue.

Quand le moteur est commun :

• la logique est moins dispersée
• les comportements restent plus cohérents
• les changements sont plus faciles à propager
• les intégrations deviennent plus propres
• la maintenance baisse

Ce que cela veut dire dans Subspace

Dans Subspace, le point important n’est pas seulement qu’il existe :

• un portail
• une API
• des SDK

Le point important est qu’ils reposent sur la même logique d’exécution.

Cela veut dire qu’un modèle n’a pas besoin d’être redéfini différemment selon qu’il est utilisé :

• depuis une interface
• par un backend
• dans un script Python
• dans une application TypeScript
• dans un workflow plus large

L’accès change. Le moteur reste le même.

Et c’est précisément cette structure qui rend Subspace plus intéressant qu’un simple ensemble d’outils séparés.

Schéma : un moteur, plusieurs portes

Ce n’est pas trois produits distincts : c’est un seul moteur, exposé selon le contexte. La capture en tête d’article (vue tableur du portail) montre concrètement la même idée : décrire le modèle et lancer le calcul sur le même spec qu’avec l’API ou le SDK ci-dessous.

Exemple minimal : API HTTP

Même principe qu’en portail : un SP Model (scénarios, pas, variables) envoyé au moteur via POST /simulate (voir la documentation développeur pour les détails).

curl -sS -X POST "https://api.subspacecomputing.com/simulate" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: be_live_..." \
  -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)"}]}'

Exemple minimal : SDK Python

from subspacecomputing import BSCE
 
client = BSCE(api_key="be_live_...")
result = client.simulate({
    "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)"},
    ],
})

Le spec est le même objet logique que celui exécutable depuis le portail ou le curl.

Pourquoi c’est important

Quand plusieurs interfaces partagent réellement le même moteur, plusieurs bénéfices apparaissent.

1. Plus de cohérence

Le comportement du modèle reste aligné quel que soit le point d’entrée.

2. Moins de duplication

La logique n’a pas besoin d’être reconstruite pour chaque contexte.

3. Moins de maintenance

Quand une logique change, on n’a pas à corriger plusieurs implémentations parallèles.

4. Meilleure intégration

On peut brancher Subspace dans un produit, un portail interne, un backend ou un script sans recréer la fondation d’exécution.

5. Plus de flexibilité

Une organisation peut commencer d’une façon, puis élargir les usages sans repartir de zéro, par exemple :

• démarrer avec le portail
• ensuite automatiser via API
• puis intégrer via SDK dans un produit ou un workflow

Sans changer de moteur.

Ce que cela change pour une organisation

Cette approche évite un problème très courant : celui où un système semble simple au début, puis se fragmente à mesure que les usages se multiplient.

Un premier besoin apparaît. Puis un autre. Puis une intégration. Puis une interface supplémentaire. Puis un usage automatisé.

Si chaque contexte exige sa propre logique, la structure devient vite plus coûteuse qu’elle n’en a l’air.

Mais si les usages s’appuient sur une même base, la croissance est beaucoup plus saine.

Le système devient :

• plus stable
• plus réutilisable
• plus évolutif
• plus facile à faire vivre dans le temps

Ce que cela change économiquement

Ce point n’est pas seulement architectural.

Il est aussi économique.

Quand plusieurs usages reposent sur une logique commune :

• le redéveloppement baisse
• la maintenance baisse
• les écarts entre implémentations baissent
• l’intégration devient plus rentable
• l’évolution du système coûte moins cher

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

Le vrai intérêt d’avoir un portail, une API et des SDK ne vient pas seulement du nombre d’options disponibles.

Il vient du fait que ces options reposent sur le même moteur d’exécution.

C’est cette base commune qui permet :

• plus de cohérence
• plus de réutilisation
• moins de duplication
• moins de maintenance
• une meilleure intégration dans plusieurs contextes

Le point important n’est donc pas seulement l’accès.

Le point important est l’unité de la logique derrière cet accès.

Et c’est précisément ce qui donne sa force à une plateforme comme Subspace.