Pourquoi nous avons conçu Open Design comme une couche de compétences, et non comme un produit

L’agent de code le plus puissant sur votre ordinateur en ce moment, c’est Claude, Codex, Cursor, Gemini, OpenCode ou Qwen. Nous ne pensons pas que vous en ayez besoin d’un de plus. Ce qui manque, ce n’est pas l’intelligence brute — c’est le goût, la structure et un flux de travail qui respecte le design comme un métier.

Open Design est notre tentative de combler cette couche manquante. Ce n’est pas un produit de chat. Ce n’est pas un outil de design qui « utilise l’IA en coulisses ». C’est une fine couche de compétences — un dossier de fichiers SKILL.md, une bibliothèque portable de systèmes de design, et un daemon qui détecte automatiquement vos agents CLI existants et les relie entre eux.

Cet article explique pourquoi nous avons fait ce choix, ce qu’il implique pour votre manière d’utiliser Open Design, et pourquoi « une couche, pas un produit » est un pari sur la longévité plutôt qu’un raccourci.

Un produit aurait la mauvaise forme

L’instinct, lorsqu’on lance un projet de design IA en 2026, est de construire une nouvelle application : une interface de chat, un canevas, un système de facturation, une facture de modèle qui croît linéairement avec votre nombre d’utilisateurs. Nous avons envisagé cette voie et l’avons rejetée pour trois raisons.

L’interface de chat est une commodité

Chaque utilisateur dispose déjà d’un agent compétent et d’une zone de chat en laquelle il a confiance. En ajouter une moins bonne — habillée de notre marque, dépourvue des automatismes qu’il a acquis — n’aide personne. L’interface n’est pas là où réside la valeur. La valeur réside dans ce que l’agent fait après que vous avez appuyé sur entrée : produire une présentation qui a l’air conçue ou un mur de divs.

La facture de modèle est une taxe sur la créativité

Intégrez l’inférence dans le produit et l’économie vous force la main. Vous devez majorer les tokens, brider les longues sessions et rationner l’accès aux modèles les plus récents pour préserver votre marge. Chacun de ces choix punit précisément le comportement qu’un outil de design devrait récompenser : itérer, explorer et relancer l’agent parce que c’est au troisième brouillon que le travail devient bon.

Le verrouillage est le mauvais réglage par défaut

Les designers devraient pouvoir partir avec leurs fichiers, leurs systèmes et leurs compétences intacts. Un produit enveloppe tout dans un état propriétaire — exportez-le et vous obtenez une ombre aplatie de la chose réelle. Une couche de compétences n’a rien à envelopper, parce que les artefacts sont les fichiers. Partir ne coûte rien, et c’est précisément pour cela que rester signifie quelque chose.

Nous avons donc construit la couche à la place. Déposez un dossier, redémarrez le daemon, la compétence apparaît. Emportez le dossier avec vous, déposez-le dans un autre agent, et la compétence y fonctionne aussi.

Ce qu’est réellement une compétence

Une compétence dans Open Design est un fichier SKILL.md accompagné d’éventuels fichiers de support dans le même dossier. Le fichier Markdown décrit :

• Ce que fait la compétence — un paragraphe, en langage clair
• Quand l’invoquer — les conditions de déclenchement, rédigées de sorte que l’agent puisse router correctement
• La forme de la sortie — HTML, PDF, diapositives, un brief en Markdown
• Les contraintes — palette en OKLch, pile de polices, posture de mise en page, vocabulaire de marque

L’agent lit le fichier, décide s’il doit l’invoquer, et écrit la sortie sur le disque. Il n’y a pas de système de plugins, pas de surface d’API, pas de matrice de compatibilité de versions. Si vous savez écrire du Markdown, vous savez livrer une compétence.

Anatomie d’une compétence

Concrètement, une compétence est un répertoire que le daemon découvre au démarrage :

skills/
  magazine-poster/
    SKILL.md          # the contract: trigger, output shape, constraints
    examples/
      launch.html     # a known-good artifact the agent can pattern-match

Le front matter du fichier SKILL.md nomme la compétence et ses déclencheurs ; le corps est une consigne que l’agent lit comme un brief. Rien n’enregistre la compétence si ce n’est sa présence sur le disque — pas de manifeste à incrémenter, pas d’étape de build, pas de file d’attente de revue.

Pourquoi les fichiers l’emportent sur les plugins

C’est intentionnel. Nous avons vu des écosystèmes de plugins se dégrader pendant quinze ans — chacun un compromis entre expressivité et longévité, remporté par aucune des deux. Un plugin est un instantané de l’API de quelqu’un à une année donnée ; le runtime évolue, l’API casse, et le flux de travail dont vous dépendiez disparaît. Les fichiers ne cassent pas. Un SKILL.md écrit aujourd’hui se lira exactement de la même façon pour un agent dans deux ans, et pour un humain sans aucun outil.

Pourquoi les systèmes sont aussi du Markdown

Open Design livre des dizaines de systèmes de design — Linear, Vercel, Stripe, Apple, Cursor, Figma, et bien d’autres — sous forme de fichiers DESIGN.md. Même idée : portables, lisibles, assimilables par l’agent.

Un système de design, dans ce contexte, n’est pas une bibliothèque Figma. C’est un contrat :

## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);

## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height

## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.

L’agent lit le contrat et produit un travail qui le respecte — des couleurs en OKLch pour qu’elles restent perceptuellement uniformes, une échelle typographique dont il ne déviera pas, une posture de mise en page qui fait que dix écrans générés donnent l’impression d’un seul produit.

Mélangez, forkez et appropriez-vous

Parce qu’un système n’est que du texte, vous pouvez en forker un et le modifier sur place, livrer une variante, ou écrire le vôtre de toutes pièces en trente minutes. Vous pouvez même mélanger des systèmes en cours de projet — prendre la typographie de Linear, la logique de couleur de Vercel, la mise en page d’une spécification interne sur mesure — parce qu’aucun format binaire ne s’interpose entre vous et les règles. Tous les mécanismes de composition des compétences et des systèmes sont détaillés dans 31 compétences, 72 systèmes : comment fonctionne la bibliothèque Open Design.

Le BYOK est le seul modèle honnête

Open Design fonctionne en bring-your-own-key. Vous collez une URL de base et une clé d’API pour n’importe quel endpoint compatible OpenAI — DeepSeek, Groq, OpenRouter, votre propre vLLM auto-hébergé — et c’est terminé :

OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…

Nous n’exécutons pas l’inférence. Nous ne prenons pas de marge sur les tokens. Nous n’avons aucune relation de facturation avec vous. Ce n’est pas un problème de viabilité — c’est la seule réponse honnête à la question « qui paie quand l’agent tourne ? ».

La confidentialité découle du même choix

Parce que le daemon appelle le fournisseur directement depuis votre machine, vos prompts ne transitent jamais par nos serveurs. Il n’y a aucun proxy pour les journaliser, aucun pipeline d’analytique qui conserve discrètement vos travaux non publiés. Pour le travail en agence ou tout ce qui relève d’un NDA, « où cela tourne-t-il ? » cesse d’être une conversation d’achat pour devenir un réglage. Les compromis plus profonds — et les aspérités qui subsistent encore — sont abordés dans le bilan de réalité du BYOK.

La réponse à la question de qui paie est : vous, directement, au fournisseur de modèle que vous avez choisi. Nous nous écartons du chemin.

Ce que cela signifie pour vous

Si vous voulez un SaaS soigné avec une jolie zone de chat et un abonnement unique, nous ne sommes pas le bon outil. Il existe de bons produits de cette forme — utilisez-les.

Si vous voulez un flux de travail où :

• l’agent auquel vous faites déjà confiance accomplit le travail,
• les compétences sont des fichiers que vous pouvez lire et modifier,
• les systèmes de design sont portables d’un projet et d’un agent à l’autre,
• et la facture va au fournisseur de modèle, pas à nous —

alors Open Design est fait pour vous. Plongez dans le dépôt GitHub, lancez pnpm tools-dev, pointez votre agent vers une compétence, et livrez.

La couche de compétences l’emporte parce qu’elle ne rivalise pas avec l’agent sur votre ordinateur. Elle l’augmente.

Lectures associées

• 31 compétences, 72 systèmes : comment fonctionne la bibliothèque Open Design — les quatre primitives sur lesquelles repose cette couche
• Flux de travail de design BYOK : exécutez Claude, Codex ou Qwen avec votre propre clé — le modèle bring-your-own-key en pratique
• L’alternative open source à Figma — où le pari « une couche, pas un produit » se situe face à l’acteur dominant