OpenCode peut-il réellement gérer le travail de design ?
Oui — avec un skill esthétique, un design system et de véritables images de référence en contexte, OpenCode produit une UI responsive de qualité production et peut la vérifier dans un navigateur. Étant agnostique en matière de modèle, vous pouvez utiliser le modèle actuellement le plus performant pour le frontend. Sans ce contexte soigneusement préparé, il a tendance à produire un rendu générique par défaut — c'est précisément le manque qu'OpenDesign vient combler.
Quel modèle utiliser avec OpenCode pour le design ?
Celui que vous préférez — OpenCode est agnostique en matière de fournisseur via models.dev, ce qui vous permet d'exécuter Anthropic, OpenAI, Google, OpenRouter ou des modèles locaux derrière le même workflow, et de changer à tout moment. La qualité du résultat dépend bien davantage de votre skill, de votre design system et de vos références que du modèle seul.
OpenDesign est-il créé par l'équipe d'OpenCode (SST) ?
Non. OpenDesign 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.
Ai-je besoin d'un abonnement spécial pour concevoir avec OpenCode ?
Non — OpenCode fonctionne en BYOK. Vous apportez votre propre clé API de fournisseur de modèle, et OpenDesign ne fait jamais transiter vos identifiants. Il n'y a aucun verrouillage fournisseur.
OpenCode, Codex ou Claude Code pour le design frontend ?
Les trois sont solides, et de nombreuses équipes les combinent. L'atout d'OpenCode est d'être entièrement open source et agnostique en matière de modèle ; Codex excelle dans les builds délégués et sandboxés ; Claude Code est reconnu pour des décisions de design précises et conscientes du codebase. OpenDesign vous permet de changer d'agent sans modifier votre workflow de design.
Ce qu’est OpenCode, précisément
OpenCode est un agent de codage 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 fournisseur, il n'embarque pas son propre modèle. Vous le pointez vers le fournisseur et le modèle de votre choix et apportez votre propre clé.
Il fonctionne comme une interface utilisateur en terminal (TUI), avec une application de bureau et des extensions d'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 — s'alternent avec la touche Tab.
Agnostique quant au modèle : les modèles et les fournisseurs proviennent de models.dev, un catalogue ouvert. Vous les configurez dans opencode.json avec une chaîne fournisseur/model-id et pouvez désactiver les fournisseurs que vous ne voulez pas charger — ainsi le même flux de travail de design tourne 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 multi-outils, également compatible avec CLAUDE.md) pour les règles du projet — l'endroit naturel pour encoder vos conventions de design. Lancez /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)
Identifiants : votre ou vos propres clés d'API de fournisseur de modèle — BYOK, sans dépendance à un fournisseur
Licence : MIT, open source
Pourquoi un agent ouvert et multi-modèles convient au travail de design
OpenCode n'a pas un unique « modèle de design » comme le fait un agent de fournisseur — et c'est précisément l'intérêt. Parce qu'il est agnostique quant au modèle et ouvert, vous pouvez exécuter le même flux de travail de design sur le modèle actuellement le meilleur en frontend, le remplacer plus tard, ou revenir à un modèle local, sans rien changer à votre configuration.
Mais le choix du modèle seul n'achète pas le bon goût. Comme tout agent de codage, OpenCode produit une interface générique si vous ne lui donnez pas de contraintes. Un bon rendu de design vient de trois apports que vous fournissez.
Un design system : de vrais tokens, des primitives et des conventions que l'agent réutilise, pour que le rendu corresponde à une marque au lieu de retomber sur un aspect générique.
Une compétence esthétique : une compétence sélectionnée avec soin qui impose un vrai goût — animation sobre, hiérarchie centrée sur la marque, au plus deux polices et une couleur d'accent — et qui pousse 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 (ordinateur et mobile, survol, vide, chargement), pas une seule image d'accroche.
Le goût vient de trois apports que vous fournissez : un design system, une compétence et de vraies images de référence — indépendamment du modèle que vous exécutez.
La leçon : OpenCode vous donne la liberté du modèle, mais le goût vient toujours d'un contexte de design soigneusement choisi. OpenDesign empaquette exactement ces apports, et c'est pourquoi les deux vont si bien ensemble — tous deux sont open source et local-first (davantage ci-dessous).
Configurer OpenCode pour le design à partir de zéro
La séquence de configuration : installer → s'authentifier (votre clé de fournisseur) → configurer AGENTS.md → ajouter une compétence → vérifier dans un vrai navigateur.
Encodez vos règles de design : placez vos tokens, primitives et conventions dans AGENTS.md (ou dans un DESIGN.md référencé depuis celui-ci) pour que le rendu corresponde à une marque au lieu de retomber sur un aspect 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 quant 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 flux de travail inchangé.
Utilisez la section sur la configuration actuelle pour les commandes et les détails propres à la version, qui peuvent changer.
# 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
Exemple de commande historique tiré du guide précédent ; vérifiez la syntaxe actuelle dans la documentation du fournisseur liée.
Workflow de la capture d’écran à l’UI dans OpenCode
La boucle de design la plus rentable avec n'importe quel agent consiste à transformer une image de référence en une interface fonctionnelle et responsive, puis à itérer jusqu'à ce qu'elle corresponde. La même forme en cinq étapes s'applique dans OpenCode.
Partez des références visuelles les plus claires dont vous disposez — et incluez plusieurs états (ordinateur et mobile, survol, vide, chargement), pas seulement une image d'accroche.
Soyez précis dans le prompt ; les prompts vagues produisent une interface générique.
Préparez un design system et indiquez à OpenCode où se trouvent les tokens et les primitives de référence (dans AGENTS.md).
Lancez un serveur de développement et faites rendre l'agent dans un vrai navigateur, en redimensionnant aux points de rupture pour vérifier le résultat.
Itérez en demandant à OpenCode de comparer son implémentation aux captures d'écran — pas simplement de confirmer que ça compile.
Référencez des fichiers avec @ dans la TUI pour une recherche floue dans votre répertoire de travail, exécutez des commandes shell en ligne avec un ! en tête, et pilotez des actions avec les commandes /. Ensuite, formulez un prompt avec des contraintes concrètes :
Gardez les prompts courts et ciblés, validez les bonnes itérations et annulez les mauvaises (en prévenant OpenCode lorsque vous annulez), pour que chaque passe s'appuie sur une base propre.
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.
Exemple de commande historique tiré du guide précédent ; vérifiez la syntaxe actuelle dans la documentation du fournisseur liée.
AGENTS.md, MCP et sessions partageables
Trois points d'extension rendent OpenCode pratique pour un travail de design soutenu, et tous les trois s'intègrent proprement à un flux de travail de design ouvert.
Règles AGENTS.md : les règles du projet résident 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 les serveurs MCP locaux (commande) et distants (URL), configurés sous la clé mcp — la manière portable d'intégrer un contexte de design et des outils externes qui fonctionnent avec plusieurs agents, pas seulement OpenCode.
Sessions partageables : la commande /share crée un lien public vers une conversation pour la collaboration ou la relecture, et /unshare le révoque — utile pour obtenir des retours sur une passe de design.
Ce sont des capacités portables et multi-agents — exactement le genre de chose qu'OpenDesign 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 empilent. Un résumé honnête :
OpenCode — Open source et agnostique quant au modèle ; exécutez n'importe quel fournisseur derrière un seul flux de travail en terminal — liberté BYOK, changement de modèle, configurations entièrement ouvertes et local-first
Codex — Belle finition visuelle avec une compétence frontend ; compréhension des images — builds asynchrones délégués, sandboxés, règles AGENTS.md portables
Claude Code — Décisions de design précises (hex, espacement, typographie) et UX consciente du codebase — raisonnement frontend et refactorisations à grand contexte
Cursor — Boucle visuelle construire-et-voir avec aperçu en direct et modifications en ligne — travail d'interface itérer-et-observer étroitement intégré à un IDE
Le verdict récurrent de la communauté est que le goût vient des humains : tous retombent par défaut sur une esthétique générique sans compétences, 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 explique précisément pourquoi un agent ouvert comme OpenCode s'associe si bien à une couche de design ouverte.
Agent — Force en design — Idéal pour
Pièges et comment éviter l’aspect « AI slop »
La plainte la plus fréquente à propos du design généré par IA est qu'il paraît générique — dégradés doux, panneaux flottants, coins très arrondis, ombres dramatiques, une ambiance Inter-et-violet qui « crie qu'une IA a fait ça ». Parmi les autres problèmes signalés figurent des mises en page mobiles cassées et des instructions qui fuient dans le texte de l'interface. Aucun de ces problèmes n'est propre à OpenCode ; c'est ce qui se produit quand n'importe quel agent tourne sans contexte de design soigneusement choisi.
Ajoutez une compétence esthétique : une compétence de design soigneusement choisie force l'agent à s'engager sur une vraie direction au lieu de l'aspect par défaut.
Vérifiez dans un vrai navigateur : rendez et contrôlez vous-même à travers les points de rupture pour que les mises en page ne se cassent pas silencieusement sur mobile.
Fournissez des tokens et des références : de vrais tokens de design et des captures d'écran de référence sont le levier le plus important sur la qualité du rendu.
Encodez les règles dans AGENTS.md : placez les règles du style « pas de cartes héro, au plus deux polices, hiérarchie centrée sur la marque » là où l'agent les lit à chaque exécution.
Remarquez que chaque mesure d'atténuation consiste à donner à l'agent un contexte de design soigneusement choisi — quel que soit le modèle que vous exécutez. Maintenir ce contexte à la main, projet par projet, c'est le labeur qu'OpenDesign supprime.
Concevoir avec OpenCode au sein d'OpenDesign
OpenDesign est la couche de design open source que le flux de travail ci-dessus ne cesse de réclamer. Il traite OpenCode comme un adaptateur de première partie et l'enveloppe dans une compétence soigneusement choisie et une bibliothèque de design systems, un pipeline de rendu structuré et une interface de bureau locale — ainsi le contexte de design qui rend n'importe quel agent bon est présent dès la première exécution, au lieu d'être assemblé à la main à chaque fois. Les deux projets sont open source et local-first, ce qui rend le duo naturel.
Authentifiez-vous avec votre propre clé d'API de fournisseur de modèle (BYOK) — les identifiants restent sur votre machine et ne passent jamais par nos serveurs.
Choisissez n'importe quel fournisseur et modèle, plus un design system et une compétence, puis générez des présentations, des prototypes et des landing pages avec un goût cohérent.
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 — plus un véritable flux de travail de design portable et open source autour. C'est local-first et Apache-2.0, donc rien de votre travail ni de vos identifiants ne quitte votre machine.
Installez OpenDesign et sélectionnez OpenCode comme agent.
De quel OpenCode s'agit-il ?
L'agent de terminal open source sur github.com/anomalyco/opencode (anciennement sst/opencode), maintenu par Anomaly. À ne pas confondre avec des outils au nom similaire.
OpenDesign est-il le même projet qu'OpenCode ?
Non. Les deux sont open source, mais ce sont des projets distincts. OpenDesign intègre OpenCode comme adaptateur d'agent de première partie.
OpenCode
OpenDesign
