Track B — Essayer un acteur dans le sandbox

](fr/track-a/setup-and-generate/) vous demande d’installer Python, copier et Docker. Track B, non. Vous restez dans l’application Kaoohi, vous travaillez par formulaires et par conversation, et la plateforme exécute tout pour vous.

Ce qu’est le sandbox kreator

Le sandbox kreator est un kompanion éphémère : une instance temporaire en cours d’exécution d’un acteur, que la plateforme démarre pour vous — et qu’elle démonte pour vous. Trois propriétés le définissent :

1. Il exécute votre brouillon d’acteur. Le sandbox démarre l’image que vous avez enregistrée : vous lui parlez donc comme le fera un utilisateur final.
2. Les connecteurs tournent en mode mock. Le kompanion du sandbox démarre avec ses connecteurs mockés. Les outils qui appelleraient des services externes reçoivent des réponses mock à la place. Aucun appel externe réel ne sort du sandbox.
3. Il est limité dans le temps. Chaque sandbox a une durée de vie. À l’expiration, le sandbox disparaît — la plateforme le récolte, et rien ne persiste.

Un sandbox est un kompanion à tous les autres égards : il sert le même endpoint de chat, la même configuration, les mêmes paramètres déclarés. Il est simplement de courte durée et délibérément coupé du monde extérieur.

Quand utiliser le sandbox

• Tester des idées. Vous voulez sentir comment un acteur se comporte avant d’investir dans une construction complète.
• Personnalisation par formulaire. Vous voulez voir comment différentes valeurs de paramètres changent le comportement de l’acteur, via le formulaire rendu.
• Tests avant soumission. Vous avez un brouillon d’acteur et voulez l’exercer avant de le soumettre à la revue.

Essayer un acteur

Le flux, du brouillon à la conversation :

1. Enregistrez un brouillon. Dans le Creator Hub, enregistrez votre acteur depuis sa référence d’image. La plateforme tire l’image OCI, extrait la configuration de l’acteur cuite dedans, et la valide (le parcours de l’assistant est décrit dans ](fr/publishing/)). Enregistrez le résultat comme brouillon — vous ne soumettez encore rien à la revue.
2. Démarrez un sandbox pour le brouillon. La plateforme lance un kompanion éphémère en mode sandbox. Cela peut prendre un moment ; un conteneur démarre.
3. Parlez-lui. Discutez avec le sandbox comme vos futurs utilisateurs le feront. Parcourez les flux de travail qui vous importent. Les connecteurs mock répondent avec de fausses données — assez pour vérifier que le flux, les prompts et la gestion des paramètres sont cohérents.
4. Laissez-le expirer — ou passez à la suite. Quand la durée de vie est épuisée, le reaper démonte le sandbox. C’est normal. Démarrez-en un nouveau dès qu’il vous faut un autre tour.

Les écrans exacts peuvent évoluer ; le flux ci-dessus est le contrat. Là où vous le voyez dans l’application, c’est la forme qu’il prend.

Personnaliser via formulaires et paramètres

Les paramètres de votre acteur sont déclarés dans sa configuration, cuite dans l’image au moment du build. La plateforme rend ces déclarations sous forme de formulaire — chaque paramètre apparaît avec le widget que son auteur lui a donné (texte, choix, interrupteur, et ainsi de suite).

Dans le sandbox, la personnalisation des paramètres est votre principal levier :

• Changez les valeurs des paramètres via le formulaire et observez comment le comportement de l’acteur évolue d’une exécution à l’autre.
• Vérifiez que les paramètres que verront vos utilisateurs sont ceux qui comptent — l’étape d’enregistrement avertit quand un acteur déclare un très grand nombre de paramètres (plus de cinquante). Un formulaire de cette taille est un signal qu’il faut simplifier.
• Gardez à l’esprit que le formulaire reflète ce qui est dans l’image. Changer des valeurs est une activité de sandbox ; changer quels paramètres existent signifie changer le code de l’acteur et construire une nouvelle image.

Les limites, sans détour

Le sandbox est réel et fonctionne aujourd’hui — dans ces bornes :

Limite	Ce que cela signifie pour vous
Connecteurs mock uniquement	Aucun appel externe réel. Un outil de réservation ne réservera rien. Vous validez des flux et des formes, pas des données réelles. Seuls les connecteurs que la plateforme sait mocker sont câblés dans le sandbox.
Durée de vie	À la date de rédaction, la politique par défaut plafonne un sandbox à environ 30 minutes, et vous permet d’en exécuter deux à la fois. Au bout du temps, tout disparaît — conversations comprises.
Budgets	Chaque session de sandbox a un budget de jetons, et la capacité sandbox de la plateforme est réduite. On peut vous refuser si les limites sont atteintes ; réessayez peu après.
Sortie réseau restreinte	Le sandbox ne peut pas joindre des endpoints réseau arbitraires.
Pas un environnement de développement	Vous ne pouvez pas éditer de code, ajouter des outils ni exécuter de tests dans le sandbox. Il exécute l’image que vous avez enregistrée — rien d’autre.

Une limite de plus, à nommer franchement : le sandbox ne construit pas d’images. Il exécute une image qui existe déjà. Produire cette image — écrire l’acteur, générer le projet, construire et pousser — c’est Track A ou le chemin IA.

Du sandbox au marketplace

Le sandbox se situe tôt dans l’entonnoir de publication :

1. Une image d’acteur avec sa configuration cuite dedans est poussée vers un registre public (GHCR par défaut).
2. Vous enregistrez la référence d’image dans le Creator Hub. La plateforme tire l’image, extrait la configuration et la valide.
3. Vous enregistrez l’acteur comme brouillon et le testez dans le sandbox — c’est votre filet de sécurité avant approbation.
4. Vous soumettez à la revue. Une fois approuvé, l’acteur apparaît dans le marketplace et les utilisateurs peuvent déployer leurs propres kompanions de celui-ci.

L’assistant d’enregistrement complet, les statuts de revue (draft, pending_review, approved, rejected, revision_requested) et ce qui se passe après approbation sont couverts dans ](fr/publishing/). Deux faits à connaître pendant que vous êtes encore dans le sandbox : vous suivez la progression de la revue dans My Actors — il n’y a pas encore de notifications ni de SLA de revue publié, revenez vérifier vous-même — et si vous mettez à jour la configuration d’un acteur déjà approuvé, la fiche en ligne conserve l’ancienne configuration jusqu’à ré-approbation de la mise à jour.

Quand passer à la suite

Restez en Track B tant que vous évaluez et réglez des paramètres. Passez à autre chose quand :

• Vous avez besoin d’appels externes réels. Les connecteurs mock ne peuvent pas confirmer une intégration réelle. Les vrais identifiants vivent dans de vrais kompanions d’acteurs approuvés — et en développement local.
• Vous avez besoin de changer le code — nouveaux outils, nouveaux prompts, nouveaux paramètres. C’est le ](fr/track-a/setup-and-generate/) (générez et éditez le projet vous-même) ou le ](fr/ai-path/), où un skill Claude Code écrit l’acteur avec vous.
• Vous avez besoin de sessions plus longues ou de persistance. Les sandboxes sont courts par conception ; un vrai kompanion est le domicile durable.

Si le code est ce que vous voulez éviter, regardez d’abord le ](fr/ai-path/) : il pose des questions structurées, puis génère et implémente l’acteur pour vous. Le sandbox devient alors l’endroit où vous testez ce qu’il a produit.