Ce que Studio est, ce qu'il n'est pas, et comment il est gouverné.

Ce qu'est Studio

Studio est un système d'orchestration pour les pipelines d'agents IA. Le travail technique passe par une configuration YAML déclarative, validée par des contrats, retentée par une boucle RALPH. Le kernel ne connaît rien du domaine. Tout le contenu métier vit dans les configs.

Studio est conçu sur le modèle de git : un outil qu'on installe globalement, qui vit dans un dossier .studio/ à l'intérieur du projet, qu'on utilise quotidiennement depuis le terminal. Pas un framework à apprendre. Pas une plateforme où s'inscrire. Un outil de développement.

git init    →  studio init
.git/       →  .studio/
git commit  →  studio run
GitHub      →  Studio Cloud (future)

Ce que Studio n'est pas

• Studio n'est pas un agent IA. Les agents sont secondaires, interchangeables, faillibles.

• Studio n'est pas un framework. Vous n'héritez pas d'une classe, vous n'implémentez pas d'interface, vous n'apprenez pas un DSL. Vous écrivez du YAML.

• Studio n'est pas une plateforme. Le kernel est open source, l'API hébergée (quand elle existera) sera optionnelle, le contenu reste dans votre repo.

• Studio n'est pas un produit commercial. Le kernel est et restera un bien commun.

Position politique

Studio est un projet explicitement ancré à gauche. Cette mention n'est pas un slogan ajouté à un produit neutre, c'est le fondement du projet lui-même. Trois principes structurent les décisions techniques et organisationnelles :

La neutralité idéologique n'est ni recherchée ni revendiquée.

Pourquoi un bien commun, pas une startup

Studio aurait pu être une startup. La forme du produit s'y prête, le marché existe, la demande monte. Le choix inverse est délibéré : un kernel d'orchestration d'agents IA, capturé par une entreprise, devient le goulot d'étranglement de tout ce qui le traverse. Studio est conçu pour ne pas pouvoir être capturé.

Trois mécanismes structurels assurent cette non-capture.

Comme GitHub, GitLab et Bitbucket le sont par rapport à git : des produits construits sur un outil libre sans autorité dessus.

Architecture technique

Studio est un monorepo de sept packages, plus un système de templates.

@studio/cli          Terminal interface
    │
@studio/engine       Orchestration, state machine, persistence
    │
    ├── @studio/ralph    Execute → validate → retry
    │
    └── @studio/runner   LLM calls, tool plugins, multi-provider
    │
@studio/contracts    Shared types (zero deps)
Templates/           Architectural patterns

Cinq concepts différencient Studio des autres orchestrateurs :

• Boucle RALPH. Exécuter, valider contre le contrat, retry avec feedback enrichi si échec, répéter jusqu'au succès ou au nombre max de tentatives. C'est ce qui rend les pipelines fiables. Aucun stage n'avance tant que sa sortie ne respecte pas son contrat.
• Contrats de sortie. Schémas de validation structurelle. La validation est binaire, succès ou échec. Pas de zone grise, pas de score d'acceptation configurable.
• Anti-théâtre. Détection des agents qui prétendent avoir fait le travail sans l'avoir fait. Si un contrat exige des appels d'outils et que l'agent n'en a fait aucun, le stage échoue quelle que soit la qualité du texte produit.
• Groupes. Boucles de feedback multi-stages. Création, critique, révision automatiques, sans intervention humaine entre les itérations.
• Tool plugins. Fichiers .tool.yaml qui définissent les capacités des agents. Auto-documentés, limités au projet, à double autorisation. Créer un outil ne nécessite pas de code.

Six invariants architecturaux assurent la cohérence du système :

1. 01Le moteur est indépendant du domaine. Tout le domaine vient du YAML.
2. 02ralph ne connaît pas runner. L'exécuteur est générique.
3. 03runner ne valide pas, ne retry pas. C'est le travail de ralph.
4. 04contracts est un package feuille. Zéro dépendances internes.
5. 05Les outils sont dans runner, pas dans engine.
6. 06Les prompts sont dans runner, pas dans engine.

Si une fonctionnalité peut être configurée en YAML plutôt que codée, elle l'est. Ce n'est pas une préférence stylistique, c'est une règle constitutionnelle du kernel.

Templates

Les templates ne sont pas des produits finis. Ce sont des patterns architecturaux qui génèrent des applications complètes, comme create-react-app ou create-next-app, mais pour des applications orchestrées par IA.

Cinq templates officiels :

Un template génère une application fonctionnelle out-of-the-box : pipelines de base pour le domaine, outils adaptés (.tool.yaml), contrats et agents configurés, schéma DB de départ (Prisma), code applicatif minimal mais fonctionnel.

studio init --template document-analysis --name wiki-creator
cd wiki-creator
npm install
studio run document-analysis/analyzer --input "..."

Les templates sont conçus pour être réutilisables. Plusieurs produits peuvent démarrer depuis le même template et diverger complètement : Wiki Creator et Voice Training utilisent tous deux le template document-analysis, mais l'un analyse des livres et l'autre traite de la voix. C'est le pattern architectural qui est partagé, pas le domaine.

Éventuellement, un registry communautaire permettra de publier et installer des templates personnalisés. Mais cette phase vient après la validation des templates officiels par des produits réels.

studio init --template @user/legal-analysis --name my-tool

Modèle de revenus

Inspiré du modèle Linus Torvalds : l'outil est gratuit, l'écosystème finance le développement.

• Le kernel est gratuit, open source, pour toujours
• Les templates officiels sont gratuits, open source
• L'API hébergée (Studio Cloud, à venir) génère des revenus par abonnements
• Les produits spécialisés peuvent être commerciaux ou open source selon les choix de chaque équipe
• La fondation est financée par l'écosystème des entreprises qui dépendent de Studio

Linus n'a jamais vendu Linux ni git. Il est financé par les entreprises qui en dépendent, via la Linux Foundation. Studio suit le même modèle. Aucune décision commerciale ne peut prendre le dessus sur les invariants du kernel. Toute évolution qui améliore les performances ou la monétisation au coût d'une aggravation des inégalités est considérée comme une régression.

Gouvernance

Le kernel est traité comme une constitution, pas comme une implémentation. L'autorité finale sur les décisions structurelles appartient au kernel et à la fondation, pas aux agents, aux produits commerciaux, ou aux contributeurs individuels.

Cinq principes opérationnels :

Cadence

• Un seul produit public à la fois
• Refus des urgences artificielles
• Toute nouvelle idée passe par une période de latence
• Le rythme humain prend le dessus sur la feuille de route
• Les templates sont créés seulement après validation par un produit réel

Studio n'est pas conçu pour scaler vite. Il est conçu pour durer.

Définition du succès

Studio est en bonne santé quand :

• Le kernel reste cohérent dans le temps
• Les projets finissent ou s'arrêtent explicitement, ils ne meurent pas par abandon
• La charge cognitive de la fondatrice et des contributeurs diminue dans le temps
• Les décisions sont traçables
• L'adoption est lente mais volontaire
• La fondatrice peut se retirer sans effondrement du système
• Les templates sont réutilisés par la communauté
• Plusieurs produits vivent sur le même template

L'argent est un moyen de durabilité, jamais une fin.

Comment contribuer

Studio est en développement actif. Trois façons de participer maintenant :

Statut

Studio est en pré-lancement. Pas encore de promotion publique. Pas encore d'API hébergée. Pas encore de version 1.0.

Une fois Code Builder validé en production, Studio passera en mode « première version publique ». En attendant, les utilisateurs intéressés peuvent suivre le repo et tester localement. Des bugs et incompatibilités sont à prévoir.