yongol — La quille du SaaS codé par IA

Le 200e endpoint

Vous construisez un SaaS en vibe coding. Au début, c’est rapide. 5 tables, 12 endpoints — vingt minutes et ça tourne.

Mais passé 50 endpoints, quelque chose d’étrange se produit. L’IA produit aujourd’hui un pattern qui contredit celui d’hier. Passé 100, des fonctionnalités existantes cassent silencieusement. Passé 200, ajouter une seule fonctionnalité coûte 10 fois plus que les dix premières.

Ce n’est pas que le modèle est stupide.

Décisions et implémentation

Trois choses sont entremêlées dans le code source :

Décisions utilisateur — cette colonne est BIGINT, cet endpoint est réservé au propriétaire, la pagination est par curseur.
Logique métier — tarification, workflows, règles de cycle de vie.
Détails d’implémentation — noms de variables, ordre des appels de bibliothèque, encapsulation des erreurs.

Quand l’IA lit ce code, elle ne peut pas distinguer quelle ligne est une décision et laquelle est un détail. Alors quand elle « refactorise » ou « nettoie », elle écrase silencieusement des décisions qu’elle a prises pour des détails. L’utilisateur ne s’en rend compte qu’une fois le comportement déjà faussé.

Voilà pourquoi le vibe coding s’effondre à 200 endpoints. Un modèle plus grand ne résout rien. Le médium — le code brut — ne préserve tout simplement pas les décisions. Chaque modèle finit par se heurter au même mur.

La quille

La quille est le premier os posé lors de la construction d’un navire. Elle supporte le poids de la coque, empêche le roulis, et toutes les autres structures sont construites par-dessus. Un navire sans quille flotte en eaux calmes mais se déforme quand les vagues arrivent.

Un SaaS construit en vibe coding, c’est pareil. Il flotte quand il est petit. Il se déforme quand il grandit.

yongol est la quille du SaaS codé par IA.

Sortir les décisions du code

Le cœur de yongol est simple. Séparer les décisions du code.

Dix spécifications déclaratives (SSOTs) gèrent chacune une seule préoccupation :

SSOT	Préoccupation
features.yaml	Catalogue de fonctionnalités — quoi construire
manifest.yaml	Configuration du projet — authentification, middleware, infrastructure
OpenAPI	Contrat API — routes, paramètres, réponses
SQL DDL + sqlc	Modèle de données — tables, colonnes, contraintes, requêtes
SSaC	Flux de service — séquence de décisions à l’intérieur d’un endpoint
Rego	Autorisation — qui peut faire quoi
Mermaid stateDiagram	Transitions d’état — cycles de vie des entités
FuncSpec	Fonctions personnalisées — logique non exprimable en CRUD
Hurl	Scénarios de test — vérification à l’exécution
STML	Frontend — structure de page et liaison de données

Huit des dix sont des standards de l’industrie (OpenAPI, SQL, sqlc, Rego, Mermaid, Hurl, YAML). Seuls SSaC et STML sont des DSL créés par yongol. Ce que l’IA doit apprendre de zéro est minimisé.

Chaque SSOT ne contient que des décisions. Aucun détail d’implémentation. L’IA édite les SSOTs ; yongol generate rend le code à partir d’eux. Les décisions vivent en permanence dans les SSOTs ; le code est une projection jetable.

Imposer la cohérence

Les décisions sont désormais réparties dans dix fichiers, donc des contradictions peuvent apparaître. DDL dit BIGINT mais OpenAPI dit string ? SSaC déclare @auth mais Rego n’a pas de règle correspondante ? Le diagramme d’états a une transition mais SSaC n’a pas de fonction correspondante ?

Un SSOT contradictoire est une décision corrompue. Aussi propre que soit le code, si les décisions se contredisent, le comportement est faux.

yongol validate attrape cela.

✓ manifest        ✓ openapi_ddl       ✓ ssac_rego
✓ openapi         ✓ openapi_ssac      ✓ ssac_authz
✓ ddl             ✓ hurl_openapi      ✓ ssac_sqlc
✓ query           ✓ hurl_statemachine ✓ ddl_statemachine
✓ ssac            ✓ hurl_manifest     ✓ ddl_rego
✓ statemachine    ✓ openapi_manifest  ✓ rego_manifest
✓ rego            ✓ ssac_ddl          ✓ stml_openapi
✓ hurl            ✓ ssac_statemachine
✓ funcspec        ✓ ssac_func

0 errors, 0 warnings

D’abord chaque SSOT est validé individuellement, puis des vérifications croisées inter-couches sont exécutées. ~287 règles inspectent chaque référence symbolique entre les dix SSOTs. S’il existe une seule contradiction, la compilation est refusée.

L’IA écrit librement. Si elle sort des rails, validate la rattrape instantanément. La liberté sur des rails.

operationId est la clé de voûte

Comment lier dix couches ensemble ? Avec un seul identifiant PascalCase.

Entrez l’operationId ExecuteWorkflow :

── Feature Chain: ExecuteWorkflow ──

  OpenAPI    api/openapi.yaml                POST /workflows/{id}/execute
  SSaC       service/workflow/execute_workflow.ssac   @get @empty @auth @state @call @publish @response
  DDL        db/workflows.sql                CREATE TABLE workflows
  DDL        db/execution_logs.sql           CREATE TABLE execution_logs
  Rego       policy/authz.rego               resource: workflow
  StateDiag  states/workflow.md              diagram: workflow → ExecuteWorkflow
  FuncSpec   func/billing/check_credits.go   @func billing.CheckCredits
  FuncSpec   func/billing/deduct_credit.go   @func billing.DeductCredit
  FuncSpec   func/worker/process_actions.go  @func worker.ProcessActions
  FuncSpec   func/webhook/deliver.go         @func webhook.Deliver
  Hurl       tests/scenario-happy-path.hurl  scenario: scenario-happy-path.hurl

De la spécification API au schéma de base de données, des politiques d’autorisation aux transitions d’état, des implémentations de fonctions aux scénarios de test — la topologie complète d’une fonctionnalité sur un seul écran. Des dizaines de grep remplacés par une commande.

operationId est la clé de voûte parce que dans une application full-stack, l’unité d’une fonctionnalité est l’endpoint API. L’utilisateur appuie sur un bouton, une API est appelée, et cette API traverse toutes les autres couches. Un nom enchaîne physiquement dix couches.

Benchmark : ZenFlow

ZenFlow — un SaaS d’automatisation de workflows multi-tenant. Claude Sonnet 4.6 a écrit les SSOTs ; yongol les a validés.

Étape	Description	Temps	Cumulé
Build initial	multi-tenant, auth, machine à états, 6 tables, 10 endpoints	23 min	23 min
+ Versioning	clone de workflow, liste de versions, copie d’actions INSERT…SELECT	16 min	39 min
+ Webhooks	publication d’événements, CRUD webhooks, backend de file d’attente	8 min	47 min
+ Marketplace de templates	pagination par curseur, clone cross-org, endpoints publics	7 min	54 min
+ Pièces jointes	rapports d’exécution, backend de fichiers	7 min	61 min
+ Planification	cron basé sur session, TTL	10 min	71 min
+ Logs d’audit	backend de cache, pagination, filtres	6 min	77 min
+ Tableau de bord	API agrégée, jointures relationnelles, vues détaillées	14 min	91 min
+ Opérations batch	sauvegarde en masse, sérialisation JSON	10 min	101 min
+ API externe	import API de géocodage, stockage de coordonnées	14 min	115 min
+ Mise à jour conditionnelle	auto-assignation, score de confiance, branchement conditionnel	16 min	131 min

Final : 30 endpoints, 12 tables, 64 requêtes de test. Tout au vert.

Dix fonctionnalités ajoutées séquentiellement. Ajouter des fonctionnalités n’a jamais ralenti. Les tests existants n’ont jamais cassé. Le mur des 200 endpoints n’existait pas.

Exécution de la même spécification avec Opus : 30 endpoints, 73 requêtes de test, ~76 min. Le modèle change, les rails restent les mêmes.

Pourquoi un plus gros modèle n’est pas la réponse

« GPT-6 réglera ça. »

Non. Le problème n’est pas l’intelligence du modèle — c’est le médium.

Le code comme médium ne distingue pas les décisions de l’implémentation. Quel que soit le modèle qui lit le code, il voit du texte où décisions et détails sont entrelacés. Aussi intelligent que soit le modèle, si le médium ne fournit pas la distinction, le modèle ne peut pas la faire.

yongol change le médium. Il déplace ce que l’IA édite du code vers des spécifications déclaratives. Comme les spécifications ne contiennent que des décisions sans détails d’implémentation, l’IA ne confond jamais une décision avec un détail. La survie des décisions devient indépendante de la taille du modèle.

Un petit LLM éditant uniquement des SSOTs, avec validate fournissant un feedback précis à chaque erreur, peut maintenir la même intégrité des décisions qu’un modèle beaucoup plus grand éditant du code brut. yongol comble cet écart.

Commencer

npx skills add park-jun-woo/yongol

Installez le skill yongol dans votre agent IA (Claude Code, Cursor, Copilot et plus). L’agent apprend le workflow à l’installation.

Pour utiliser le CLI directement :

go install github.com/park-jun-woo/yongol/cmd/yongol@latest

git clone https://github.com/park-jun-woo/yongol && cd yongol
yongol validate examples/zenflow

0 errors, 0 warnings.

Dirigez une IA vers ces spécifications et demandez-lui d’ajouter une fonctionnalité. validate pose les rails ; l’IA court dessus. Il n’y a pas de mur.