Fragments d'E2B : un gabarit Next.js pour générer et exécuter du code dans un bac à sable

Le problème visé : générer du code ne suffit pas, il faut l'exécuter

Un modèle de langage produit volontiers du React, du Python ou une application Streamlit. Encore faut-il lancer le résultat quelque part sans exposer sa machine. Fragments prend en charge cette seconde moitié du travail. Le README le présente comme une version open source de ce que font les artefacts de Claude, v0 de Vercel ou GPT Engineer, et le dépôt est publié par E2B sous licence Apache-2.0. Le public visé est donc précis : développeurs à l'aise avec Next.js qui veulent une interface de génération de code dont ils contrôlent le code source, mais qui acceptent de déléguer l'isolation d'exécution à un service tiers. Ce n'est pas un outil pour quelqu'un qui cherche un générateur de site prêt à l'emploi sans écrire de configuration.

Ce que fait réellement le SDK E2B entre le modèle et l'utilisateur

Le README indique que le projet s'appuie sur le E2B SDK pour exécuter de manière sécurisée le code produit par l'IA. La pile annoncée est Next.js 14 avec App Router et Server Actions, shadcn/ui, TailwindCSS et le Vercel AI SDK. Les réponses du modèle sont diffusées en flux dans l'interface. Le point d'articulation est ailleurs : chaque persona est décrite par un identifiant de template, une liste de dépendances, un fichier d'entrée, des instructions envoyées au modèle et un port optionnel. Le sandbox correspondant doit exister côté E2B, construit à partir d'un e2b.Dockerfile. Autrement dit, le modèle n'écrit pas dans un environnement libre : il écrit dans une image que vous avez préparée, avec les paquets que vous avez listés. C'est la contrainte structurante du projet, et c'est aussi ce qui le rend présentable en production. Le README mentionne également une intégration avec le modèle Apply de Morph, présentée comme une édition de code plus économe en tokens, activée par défaut via MORPH_API_KEY.

Mise en route : les commandes et les clés qui comptent

Le parcours documenté tient en cinq étapes. Cloner le dépôt avec git clone https://github.com/e2b-dev/fragments.git, entrer dans le dossier, puis npm i. Vient ensuite le fichier .env.local, où E2B_API_KEY est obligatoire, tout comme au moins une clé de fournisseur parmi OPENAI_API_KEY, ANTHROPIC_API_KEY, GROQ_API_KEY, FIREWORKS_API_KEY, TOGETHER_API_KEY, GOOGLE_AI_API_KEY, GOOGLE_VERTEX_CREDENTIALS, MISTRAL_API_KEY ou XAI_API_KEY. Le reste est facultatif : MORPH_API_KEY, NEXT_PUBLIC_SITE_URL, RATE_LIMIT_MAX_REQUESTS et RATE_LIMIT_WINDOW, KV_REST_API_URL et KV_REST_API_TOKEN pour Vercel ou Upstash, SUPABASE_URL et SUPABASE_ANON_KEY pour l'authentification, NEXT_PUBLIC_POSTHOG_KEY et NEXT_PUBLIC_POSTHOG_HOST pour l'analytique. Deux variables servent à masquer des fonctions de l'interface : NEXT_PUBLIC_NO_API_KEY_INPUT et NEXT_PUBLIC_NO_BASE_URL_INPUT retirent la saisie de clé et d'URL de base dans le chat, NEXT_PUBLIC_HIDE_LOCAL_MODELS cache les modèles locaux. Le lancement se fait avec npm run dev, la construction avec npm run build. Notez que le README liste les fournisseurs pris en charge avec des puces, ce qui n'est pas une garantie de parité de comportement entre eux.

Ajouter une persona : Dockerfile, e2b.toml, puis une entrée JSON

C'est la partie du dépôt qui demande le plus de soin. Le README demande d'installer le CLI E2B et de s'y connecter, de créer un dossier sous sandbox-templates/, puis de lancer e2b template init pour obtenir un e2b.Dockerfile. L'exemple fourni part de python:3.19-slim, installe streamlit, pandas, numpy, matplotlib, requests, seaborn et plotly, copie le code dans /home/user. Le fichier e2b.toml porte la commande de démarrage, par exemple start_cmd = "cd /home/user && streamlit run app.py". La construction se fait avec e2b template build --name <template-name>, et le README indique qu'un message de fin s'affiche avec l'identifiant du template. Il faut ensuite déclarer la persona dans lib/templates.json avec une clé, un name, la liste lib des dépendances, le champ file, des instructions et un port, 8501 dans l'exemple Streamlit, avec la mention que ce port peut être null. Un logo peut être ajouté sous public/thirdparty/templates. À noter : l'exemple de Dockerfile du README utilise python:3.19-slim, une balise qui ne correspond à aucune version publiée de Python, et le README renvoie deux fois au même fichier sous deux noms différents, lib/templates.json puis lib/models.json, avant de citer lib/models.ts pour les modèles. Ces incohérences se règlent en lisant l'arborescence du dépôt, pas en suivant le texte à la lettre.

Modèles et fournisseurs : une configuration par listes

L'ajout d'un modèle passe par une entrée avec id, name, provider et providerId, l'exemple donné étant mistral-large chez Ollama. L'ajout d'un fournisseur passe par providerConfigs, avec l'exemple Fireworks construit via createOpenAI en pointant sur https://api.fireworks.ai/inference/v1. Une fonction getDefaultMode permet de forcer un mode de sortie structurée, ici json pour Fireworks. Cette architecture en listes est simple à étendre, mais elle suppose que le fournisseur expose une API compatible avec le SDK utilisé. Le README ne décrit pas de mécanisme d'adaptation pour les fournisseurs qui s'en écartent, ni de test de conformité entre ce que le modèle renvoie et ce que la persona attend comme fichier d'entrée. C'est un point à vérifier soi-même avant d'ajouter un fournisseur exotique.

La dépendance à E2B est le vrai arbitrage

Fragments n'exécute rien lui-même. Le README précise que l'exécution passe par le SDK E2B, et le CLI E2B est requis pour construire les templates. Si votre contrainte est de faire tourner le code généré sur votre propre cluster, ou si vous devez passer par une validation interne avant de pousser une image, ce projet ne vous aide pas : il faudrait remplacer la couche d'exécution, ce qui revient à réécrire la partie la plus délicate. Deuxième limite, la personnalisation d'une persona dépend d'un aller-retour avec le CLI et d'un service externe, donc d'une clé et d'un compte. Troisième, le README ne documente pas de mode dégradé quand aucun template n'est disponible pour la persona demandée, ni la manière dont les erreurs d'exécution remontent dans l'interface. Sur un projet destiné à des utilisateurs finaux, cette absence de description est gênante.

Face à quoi comparer, et sur quel critère

Les artefacts de Claude, v0 de Vercel et GPT Engineer sont cités par le README comme les équivalents propriétaires de cette idée. La différence d'approche tient à qui contrôle le bac à sable. Chez ces produits, l'environnement d'exécution est fourni et vous n'avez ni Dockerfile à écrire ni template à construire. Avec Fragments, vous héritez du code Next.js et de la définition des personas, mais vous héritez aussi de la construction des images et de la gestion des clés. Le choix se fait donc sur ce critère, pas sur la qualité de l'interface de chat. Un autre point de comparaison interne au dépôt : les personas Python et Streamlit sont décrites avec leurs ports et leurs dépendances, alors qu'aucun exemple de persona Next.js ou Vue n'est détaillé dans le README, même si ces piles figurent dans la liste des piles prises en charge.

Coût de maintenance et cadre de licence

Le dépôt est publié sous Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et du fichier de licence. Ce texte n'est pas un avis juridique : faites relire le fichier LICENSE du dépôt si la redistribution est prévue. Le coût de maintenance réel se situe ailleurs. Le projet suit Next.js 14, le Vercel AI SDK et le SDK E2B, trois dépendances qui bougent vite, et le README ne décrit aucune politique de version ni de compatibilité. Chaque ajout de fournisseur ou de persona est une modification de configuration à maintenir, et chaque template construit côté E2B devient un artefact à reconstruire quand les dépendances qu'il embarque vieillissent. Le dépôt n'est pas archivé et la dernière poussée enregistrée date du 9 septembre 2026, mais aucun numéro de version n'a été récupéré, ce qui empêche de juger la cadence de publication. Vérifiez ce point vous-même si vous prévoyez de suivre la branche main.

Conclusion éditoriale

Fragments convient à une équipe qui veut héberger elle-même une interface de génération de code et qui accepte de dépendre d'E2B pour l'exécution. À éviter si vous voulez exécuter le code généré sur votre propre infrastructure, ou si vous ne pouvez pas faire valider un Dockerfile personnalisé par le CLI E2B. Avant d'adopter, vérifiez deux points précis : que le nom de fichier réellement lu par le code est bien lib/templates.json ou lib/models.ts selon la section du README concernée, et que chaque persona déclarée dispose d'un template E2B construit et accessible avec votre clé.

Sources officielles

1. e2b-dev/fragments on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README