OpenCode pour le design.

Ce qu’est réellement OpenCode

OpenCode est un agent de code IA open source conçu pour le terminal, maintenu par l’équipe derrière SST (Anomaly Innovations). Il lit votre dépôt, exécute des commandes, modifie des fichiers et dialogue avec un grand modèle de langage — mais, contrairement aux agents liés à un éditeur, il ne fournit pas son propre modèle. Vous le pointez vers le fournisseur et le modèle de votre choix et apportez votre propre clé.

Il s’exécute comme une UI en terminal (TUI), avec une application desktop et des extensions IDE par-dessus le même moteur. Sous le capot, il utilise une architecture client/serveur, de sorte que l’agent qui fait le travail est découplé de la surface depuis laquelle vous le pilotez. Deux agents intégrés — build et plan — se basculent avec la touche Tab.

• Agnostique au modèle: Les modèles et fournisseurs proviennent de models.dev, un catalogue ouvert. Vous les configurez dans opencode.json avec une chaîne provider/model-id et pouvez désactiver les fournisseurs que vous ne voulez pas charger — le même workflow de design s’exécute ainsi sur Anthropic, OpenAI, Google, OpenRouter, des modèles locaux et plus encore.
• Fichier d’instructions: OpenCode lit un fichier AGENTS.md dans votre projet (le standard inter-outils, également compatible avec CLAUDE.md) pour les règles de projet — l’endroit naturel pour encoder vos conventions de design. Exécutez /init pour en générer un.
• Extensible: Il prend en charge l’intégration LSP, les serveurs MCP, les thèmes, les raccourcis clavier et les commandes personnalisées, ainsi que des liens de session partageables pour la collaboration.

• Mainteneur : SST / Anomaly Innovations (projet open source)
• Identifiant : votre/vos propre(s) clé(s) API de fournisseur de modèle — BYOK, sans verrouillage par l’éditeur
• Licence : MIT, open source

Pourquoi un agent ouvert et tout-modèle convient au travail de design

OpenCode n’a pas un unique « modèle de design » comme en a un agent d’éditeur — et c’est tout l’intérêt. Parce qu’il est agnostique au modèle et ouvert, vous pouvez exécuter le même workflow de design sur le modèle actuellement le meilleur en frontend, en changer plus tard, ou vous rabattre sur un modèle local, le tout sans modifier votre configuration.

Mais le choix du modèle seul n’achète pas le goût. Comme tout agent de code, OpenCode produit une UI générique tant que vous ne lui donnez pas de contraintes. Une bonne sortie de design provient de trois entrées que vous fournissez.

• Un design system: De vrais tokens, primitives et conventions que l’agent réutilise, pour que les sorties correspondent à une marque au lieu de retomber sur un rendu générique.
• Une skill esthétique: Une skill organisée qui impose un vrai goût — mouvement sobre, hiérarchie qui met la marque d’abord, deux familles typographiques et une couleur d’accent au maximum — et amène l’agent à s’engager sur une direction avant de construire.
• Des références concrètes: De vraies images de référence et plusieurs états (desktop et mobile, survol, vide, chargement), pas un unique visuel héros.

La leçon : OpenCode vous donne la liberté du modèle, mais le goût vient toujours d’un contexte de design organisé. Open Design empaquette précisément ces entrées, et c’est pourquoi les deux s’accordent — tous deux sont open source et local-first (plus de détails ci-dessous).

Configurer OpenCode pour le design, à partir de zéro

Voici le parcours complet, d’une machine vierge à un OpenCode capable de construire et de vérifier des UI.

# 1. Install OpenCode
curl -fsSL https://opencode.ai/install | bash
# or: npm i -g opencode-ai@latest
# or: brew install sst/tap/opencode

# 2. Start the TUI in your project, then authenticate your provider
opencode          # then run /login and pick your provider + paste your key

# 3. Generate project context
opencode          # inside your project, run /init to create AGENTS.md

# 4. Pick your model (any provider, via models.dev)
#    set "provider/model-id" in opencode.json or switch in the TUI

# 5. Add an MCP server (optional, e.g. for design handoff)
#    configure it under the "mcp" key in opencode.json

• Encodez vos règles de design: Mettez vos tokens, primitives et conventions dans AGENTS.md (ou un DESIGN.md référencé depuis lui) pour que les sorties correspondent à une marque au lieu de retomber sur un rendu générique. L’option instructions dans opencode.json peut pointer vers des fichiers de règles supplémentaires via des globs.
• Choisissez un modèle capable: Parce qu’OpenCode est agnostique au modèle, choisissez le fournisseur/modèle actuellement le plus fort en frontend pour la passe de design — et gardez le reste de votre workflow inchangé.

Le workflow capture-vers-UI

La boucle de design la plus efficace avec n’importe quel agent consiste à transformer une image de référence en une UI fonctionnelle et responsive, puis à itérer jusqu’à ce qu’elle corresponde. La même structure en cinq étapes s’applique dans OpenCode.

1. Partez des références visuelles les plus claires dont vous disposez — et incluez plusieurs états (desktop et mobile, survol, vide, chargement), pas seulement un visuel héros.
2. Soyez précis dans le prompt ; des prompts vagues produisent une UI générique.
3. Préparez un design system et indiquez à OpenCode où se trouvent les tokens et les primitives canoniques (dans AGENTS.md).
4. Faites tourner un serveur de dev et faites rendre l’agent dans un vrai navigateur, en redimensionnant aux breakpoints pour contrôler le résultat.
5. Itérez en faisant comparer à OpenCode son implémentation avec les captures — au lieu de simplement confirmer que ça build.

Référencez des fichiers avec @ dans le TUI pour une recherche floue de votre répertoire de travail, exécutez des commandes shell en ligne avec un ! en tête, et déclenchez des actions avec les commandes /. Puis formulez le prompt avec des contraintes concrètes :

opencode
# in the TUI:
> @reference-desktop.png @reference-mobile.png
  Implement this design in React + Vite + Tailwind + TypeScript.
  Reuse my existing design-system components and tokens from AGENTS.md.
  Match spacing, layout, and hierarchy; make it responsive.
  Run the dev server, open it in a browser, and iterate until the
  UI matches the references across breakpoints.

Gardez des prompts courts et ciblés, committez les bonnes itérations et annulez les mauvaises (en prévenant OpenCode quand vous revenez en arrière), pour que chaque passe parte d’une base propre.

AGENTS.md, MCP et sessions partageables

Trois points d’extension rendent OpenCode pratique pour un travail de design durable, et tous trois se projettent proprement sur un workflow de design ouvert.

• Règles AGENTS.md: Les règles de projet vivent dans un AGENTS.md à la racine du dépôt (ou des règles globales dans ~/.config/opencode/AGENTS.md). C’est le foyer durable de vos conventions de design, lu à chaque exécution, et il est compatible avec les fichiers CLAUDE.md qu’utilisent d’autres agents.
• Serveurs MCP: OpenCode prend en charge à la fois les serveurs MCP locaux (command) et distants (URL), configurés sous la clé mcp — la façon portable d’apporter du contexte de design et des outils externes qui fonctionnent à travers les agents, pas seulement OpenCode.
• Sessions partageables: La commande /share crée un lien public vers une conversation pour la collaboration ou la revue, et /unshare le révoque — utile pour obtenir des retours sur une passe de design.

Ce sont des capacités portables et multi-agent — exactement le genre de chose qu’Open Design est conçu pour orchestrer, plutôt que de recréer projet par projet.

OpenCode vs Codex vs Claude Code vs Cursor pour le design

Il n’y a pas de vainqueur unique pour le travail de design — chaque agent a une force différente, et les équipes expérimentées les combinent. Un résumé équilibré :

Le verdict récurrent de la communauté est que le goût vient des humains : tous retombent sur une esthétique générique sans skills, références et contraintes. C’est le vrai problème à résoudre — et il a la forme d’un outil de design, pas d’un modèle, ce qui est précisément pourquoi un agent ouvert comme OpenCode s’accorde si bien avec une couche de design ouverte.

Les pièges, et comment éviter le rendu « AI slop »

La critique la plus fréquente à l’égard du design généré par IA est qu’il a l’air générique — dégradés doux, panneaux flottants, coins arrondis surdimensionnés, ombres spectaculaires, une ambiance Inter-et-violet qui « crie qu’une IA a fait ça ». Parmi les autres problèmes signalés : des mises en page mobiles cassées et des instructions qui fuient dans les textes de l’UI. Aucun de ces problèmes n’est propre à OpenCode ; c’est ce qui arrive quand un agent, quel qu’il soit, s’exécute sans contexte de design organisé.

• Ajoutez une skill esthétique: Une skill de design organisée force l’agent à s’engager sur une vraie direction au lieu du rendu par défaut.
• Vérifiez dans un vrai navigateur: Rendez et auto-contrôlez sur les différents breakpoints pour que les mises en page ne cassent pas en silence sur mobile.
• Fournissez tokens et références: De vrais tokens de design et des captures de référence sont le plus grand levier sur la qualité des sorties.
• Encodez les règles dans AGENTS.md: Mettez des règles de style comme « pas de hero cards, deux familles typographiques au maximum, hiérarchie qui met la marque d’abord » là où l’agent les lit à chaque exécution.

Remarquez que chaque parade revient à donner à l’agent un contexte de design organisé — quel que soit le modèle que vous exécutez. Maintenir ce contexte à la main, projet par projet, est le labeur qu’Open Design supprime.

Concevoir avec OpenCode dans Open Design

Open Design est la couche de design open source que le workflow ci-dessus ne cesse de réclamer. Il traite OpenCode comme un adaptateur de première partie et l’entoure d’une bibliothèque organisée de skills et de design systems, d’un pipeline de rendu structuré et d’une UI desktop locale — pour que le contexte de design qui rend tout agent bon soit présent dès la première exécution, et non assemblé à la main à chaque fois. Les deux projets sont open source et local-first, ce qui rend l’appariement naturel.

1. Installez Open Design et sélectionnez OpenCode comme agent.
2. Authentifiez-vous avec votre propre clé API de fournisseur de modèle (BYOK) — les identifiants restent sur votre machine et ne transitent jamais par nos serveurs.
3. Choisissez n’importe quel fournisseur et modèle, plus un design system et une skill, puis générez des decks, des prototypes et des landing pages avec un goût cohérent.
4. Chaque artefact et fichier DESIGN.md vit dans votre propre dépôt, pas dans un cloud hébergé.

Le même agent OpenCode, la même liberté de modèle — auxquels s’ajoute un véritable workflow de design open source, portable, autour de lui. C’est local-first et Apache-2.0, donc rien de votre travail ni de vos identifiants ne quitte votre machine.

Questions fréquentes

1. 01 OpenCode peut-il vraiment faire du travail de design ? +

   Oui — avec une skill esthétique, un design system et de vraies images de référence dans le contexte, OpenCode produit une UI responsive de qualité production et peut la vérifier dans un navigateur. Parce qu’il est agnostique au modèle, vous exécutez celui qui est actuellement le meilleur en frontend. Sans ce contexte organisé, il a tendance à retomber sur un rendu générique, et c’est l’écart que comble Open Design.

2. 02 Quel modèle utiliser avec OpenCode pour le design ? +

   Celui que vous voulez — OpenCode est agnostique au fournisseur via models.dev, vous pouvez donc exécuter Anthropic, OpenAI, Google, OpenRouter ou des modèles locaux derrière le même workflow et en changer à tout moment. La qualité de la sortie de design dépend bien plus de votre skill, de votre design system et de vos références que du modèle seul.

3. 03 Open Design est-il fait par l’équipe OpenCode (SST) ? +

   Non. Open Design est un projet open source indépendant qui intègre OpenCode comme agent. Il complète OpenCode avec une bibliothèque de skills et de design systems ouverte et local-first.

4. 04 Ai-je besoin d’un abonnement spécial pour concevoir avec OpenCode ? +

   Non — OpenCode est BYOK. Vous apportez votre propre clé API de fournisseur de modèle, et Open Design ne fait jamais transiter vos identifiants. Il n’y a pas de verrouillage par l’éditeur.

5. 05 OpenCode, Codex ou Claude Code pour le design frontend ? +

   Tous sont solides, et beaucoup d’équipes les combinent. L’avantage d’OpenCode est d’être entièrement open source et agnostique au modèle ; Codex excelle dans les builds délégués en sandbox ; Claude Code est reconnu pour ses décisions de design précises et conscientes de la base de code. Open Design vous laisse changer d’agent sans changer votre workflow de design.

6. 06 Comment étendre OpenCode pour le contexte de design ? +

   Encodez les règles dans AGENTS.md, ajoutez des serveurs MCP sous la clé mcp pour des outils portables et du contexte de design, et utilisez les sessions partageables pour la revue. Open Design fournit une bibliothèque organisée de skills et de design systems pour vous éviter la configuration projet par projet.

7. 07 Open Design est-il affilié à OpenCode ou SST ? +

   Non. OpenCode est un projet open source maintenu par SST (Anomaly Innovations) ; Open Design est un projet open source indépendant qui le prend en charge comme adaptateur de première partie.

8. 08 Mes fichiers et identifiants sont-ils en sécurité ? +

   Oui — Open Design est local-first. Vos fichiers, artefacts et DESIGN.md restent dans votre propre dépôt, et vos identifiants de fournisseur de modèle sont utilisés directement par votre agent, jamais routés via les serveurs d’Open Design.