À quoi ressemble un modèle dans Subspace

Quand on parle de modèles analytiques, de projections ou de simulations, beaucoup de discussions restent abstraites.

On parle de logique, d’exécution, de scénarios, d’intégration, de résultats.

Mais à un moment, il faut rendre les choses concrètes.

Il faut pouvoir répondre à une question simple :

à quoi ressemble réellement un modèle dans Subspace ?

Le problème, dans beaucoup d’environnements, n’est pas seulement le calcul

Dans beaucoup d’organisations, la logique métier finit par être enfouie :

• dans des fichiers
• dans plusieurs feuilles
• dans des scripts
• dans des règles dispersées
• dans des ajustements difficiles à retracer
• dans des enchaînements que peu de gens peuvent relire rapidement

Le modèle fonctionne parfois.

Mais sa structure devient difficile à lire, difficile à réutiliser et difficile à faire évoluer.

Le problème n’est donc pas seulement ce que le modèle calcule.

Le problème est aussi dans quelle forme cette logique existe.

Une autre approche : rendre la logique plus visible

Dans Subspace, l’objectif n’est pas de cacher la logique derrière une boîte noire.

L’objectif est au contraire de la rendre plus claire, plus structurée et plus réutilisable.

Un modèle Subspace décrit explicitement ce qui doit être exécuté :

• le nombre de scénarios
• le nombre de pas
• les variables
• les distributions
• les formules
• les outputs attendus

Autrement dit, la logique ne disparaît pas dans son support.

Elle devient un objet plus lisible.

À quoi ressemble un modèle simple

Prenons un exemple volontairement simple.

On veut projeter un capital sur 12 pas, avec 1000 scénarios.

Le taux varie selon une distribution uniforme entre 3 % et 7 %.

Le capital évolue à chaque pas selon ce taux, et on calcule ensuite le profit.

Dans Subspace, cette logique peut être décrite comme ceci :

{
  "steps": 12,
  "scenarios": 1000,
  "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]"
    }
  ]
}

Le modèle n’est pas seulement exécuté. Il est décrit.

Ce qui compte ici, ce n’est pas seulement le JSON lui-même.

Ce qui compte, c’est qu’on voit clairement :

• les paramètres de simulation
• les variables
• la logique d’évolution
• la relation entre les éléments

Le modèle devient relisible.

Le même modèle dans le portail

Dans le portail Subspace, cette même logique peut être visualisée de plusieurs façons :

• en vue tableur
• en vue schéma
• en résultats
• en graphiques

Cela permet à différents profils de travailler avec le même modèle selon leur besoin :

• lecture structurée
• compréhension des dépendances
• validation des résultats
• intégration à un workflow

Vue tableur : zoom sur la grille Modèle

L’image d’en-tête situe le modèle dans le portail ; la capture ci-dessous zoome sur la grille : scénarios, pas, variables taux, capital et profit, avec les mêmes init et formules que dans le SP Model.

Vue schéma : dépendances entre variables

Résultats et graphiques après un run

Le point important n’est pas que l’interface soit jolie.

Le point important est que le portail s’appuie sur la même logique décrite dans le modèle.

Ce que cela change

Quand un modèle est mieux structuré :

• il est plus visible
• il est plus portable
• il est plus simple à modifier
• il est plus facile à relire
• il est plus naturel à intégrer
• il dépend moins d’un seul support ou d’une seule personne

Le modèle ne reste plus coincé dans un fichier, un script ou une logique implicite.

Il devient une structure plus claire, capable de vivre dans plusieurs contextes.

Ce n’est pas seulement plus propre

Ce point peut sembler surtout esthétique ou technique au premier regard.

Mais en réalité, il a des conséquences très concrètes.

Quand la logique est mieux décrite :

• les changements coûtent moins cher à absorber
• la réutilisation devient plus simple
• les intégrations demandent moins de reconstruction
• la compréhension du modèle s’améliore
• la maintenance devient moins fragile

Autrement dit, une meilleure structure n’est pas seulement un confort.

C’est aussi une façon de réduire la charge autour du modèle.

Ce qu’un modèle structuré rend possible

Une fois le modèle décrit clairement, il peut ensuite être :

• exécuté dans le portail
• appelé via API
• utilisé dans un script Python
• intégré à une application TypeScript
• repris dans un autre workflow

Le modèle n’est donc pas seulement un objet qu’on lit.

C’est une logique exécutable qui peut circuler plus proprement dans l’organisation.

Conclusion

À partir d’un certain niveau de complexité, la question n’est plus seulement :

est-ce que le modèle fonctionne ?

La question devient aussi :

dans quelle structure vit-il, et que permet cette structure ?

Dans Subspace, un modèle n’est pas seulement un calcul caché derrière une interface.

C’est une logique décrite de façon plus claire, exécutable dans un moteur commun, et réutilisable dans plusieurs contextes.

C’est précisément ce qui le rend plus intéressant à faire vivre dans le temps.