Combien de tokens fait une application métier ? Un CRM complet sous 150k

La version courte : un CRM complet tient sous 150 000 tokens de métadonnées typées : la logique métier — chaque objet, workflow, action et permission — reste sous 100 000, tandis que l’UI déclarative ajoute environ 50 000. La référence app-crm fournie est encore plus petite : 1 792 lignes réparties sur 31 fichiers, soit environ 16 000 tokens. Ces 16k décrivent l’échantillon de référence, pas le plafond d’un CRM complet de niveau produit. Les deux tiennent dans une fenêtre de 200k. C’est un logiciel à taille de contexte : l’AI peut tenir, raisonner et refactoriser l’application entière pendant qu’un humain relit le diff.

Comptez vous-même

Les 16k ne sont pas un benchmark de produit complet. C’est le décompte reproductible de la référence CRM livrée avec le framework open source ObjectStack :

git clone https://github.com/objectstack-ai/objectstack
find objectstack/examples/app-crm/src -name '*.ts' -not -name '*.test.ts' \
  | xargs cat | wc -l
# → 1 792 lignes dans 31 fichiers ≈ 16k tokens (à ~4 caractères par token)

Système	Fichiers	Lignes	≈ Tokens	Tient dans 200k de contexte ?
CRM d’exemple (`app-crm`) — objets, vues, tableau de bord, flux, permissions, traductions	31	1 792	~16k	Oui — 12× de marge
HotCRM — CRM complet de marketplace : 15 objets, 17 flux, 4 tableaux de bord, 2 copilotes AI, 4 langues	132	~18 000	moins de 150k au total (logique métier sous 100k + UI ~50k)	Oui — plus de 50k de marge
Une base de code CRM conventionnelle écrite à la main	des milliers	300k–1M+	des millions	Non — loin de là

Même catégorie de produit, deux échelles utiles : un échantillon de référence à environ 16k et un CRM complet sous 150k. Les deux ont une taille de contexte ; une base de code conventionnelle, non.

Pourquoi le token est devenu la bonne unité

Pendant cinquante ans, nous avons mesuré le logiciel en lignes de code, parce que la contrainte déterminante était le lecteur humain. Le lecteur a changé. Avant qu’un agent AI puisse modifier un système en sécurité, il doit le charger — ce qui place toute base de code dans l’un de deux régimes :

Système plus grand que le contexte. L’agent greppe, échantillonne, devine. Ses modifications sont locales ; ses erreurs, globales. Chaque changement est de l’archéologie à travers un trou de serrure.
Système plus petit que le contexte. L’agent lit tout — chaque objet, chaque règle de permission, chaque dépendance — en une passe. « Qu’est-ce qui casse si je change ceci ? » devient une question à laquelle on peut répondre, pas un espoir. Un changement transversal — renommer un concept dans le modèle de données, les permissions, l’API et l’UI — est un seul diff cohérent.

Ce n’est pas une amélioration incrémentale. C’est un changement de régime, et la frontière passe là où se trouve votre fenêtre de contexte.

Pourquoi la logique métier reste sous 100k tokens

Pas par un tour de compression — par suppression. Une application d’entreprise, ce sont deux choses entrelacées :

Les décisions. Quels objets existent, comment ils se relient, qui peut voir quel champ, ce qui se passe quand un lead convertit. C’est votre ontologie métier, et elle est véritablement irréductible — vous seul pouvez la décider.
La plomberie. Tables, endpoints CRUD, écrans liste et détail, middleware de permissions, écritures d’audit. C’est essentiellement identique dans toutes les applications métier jamais écrites — donc dérivable.

Le pari d’ObjectStack : ne garder que les décisions dans l’artefact et dériver toute la plomberie au runtime. Dans le CRM de référence fourni, ces 1 792 lignes sont la liste des décisions — des métadonnées typées, validées par Zod. Le schéma de base de données, l’API REST, l’UI rendue et les outils MCP en sont calculés à chaque démarrage. Rien de dérivable n’est stocké, donc rien ne peut dériver. Dans le HotCRM complet, cette séparation maintient la logique métier sous 100k tokens ; l’UI déclarative ajoute environ 50k et garde l’application entière sous 150k.

Ce qui ne se compresse pas

L’honnêteté sur la frontière compte plus que l’argumentaire :

Les algorithmes inédits. Un optimiseur de prix ou un moteur d’appariement sur mesure est du vrai code et le restera. Le format a des issues de secours — les actions et les plugins sont du TypeScript ordinaire.
Les expériences sur mesure au pixel près. L’UI pilotée par schéma rend très bien les motifs d’entreprise ; ce n’est pas ainsi qu’on construit un site de marque ou un jeu.
Les intégrations exotiques. Le connecteur vers un service SOAP vieux de trente ans reste du code de connecteur.

L’affirmation est donc plus étroite que « tout devient métadonnée » — et d’autant plus forte : le cœur CRUD-plus-workflow qui constitue l’essentiel du logiciel d’entreprise est dérivable, et le résidu qui compte vraiment — l’ontologie — tient dans le contexte.

Ce qui change quand le logiciel est à taille de contexte

La revue devient réelle. 1 792 lignes, c’est une revue de code. 300 000 lignes, c’est un rituel. Un humain peut lire le diff entier ; la porte de validation et l’application des permissions et de l’audit par le runtime assurent le reste.
La maintenance cesse de pourrir. Quand tout le système tient dans le contexte, l’agent le refactorise en entier au lieu de rapiécer ce qu’il voit. La courbe d’entropie habituelle du logiciel d’entreprise — chaque changement un peu plus risqué que le précédent — s’aplatit.
L’ontologie reste la vôtre. La définition est un format ouvert Apache-2.0, des fichiers ordinaires dans votre dépôt — lisibles par des humains, inscriptibles par n’importe quel agent, portables entre runtimes.

Essayez la boucle

Pointez votre agent de code vers ObjectStack — le scaffold embarque AGENTS.md et le bundle de skills, l’agent démarre donc avec les règles du format déjà chargées :

npm create objectstack@latest my-app && cd my-app
npx os dev --ui   # l’app tourne — décrivez le prochain changement à votre agent

Vous préférez le navigateur à un dépôt ? ObjectOS est la même idée, opérée pour vous — construire et interroger en ligne, avec l’AI Builder, les permissions et l’audit intégrés.