La couche de mise en page que le canvas masquait

Une réponse utile de la communauté ne demande pas un plus gros bouton. Elle nomme la couche manquante.

C'est ce qui s'est passé sous la discussion Open Design 0.8.0-preview. Le fil de lancement plaidait pour deux changements : cesser de traiter le canvas comme l'unité de travail principale, et faire de l'agent le travailleur de design de première classe. Une réponse était d'accord avec la direction, puis a pointé la partie difficile : quand le canvas disparaît, les utilisateurs ont toujours besoin d'un moyen de comprendre ce que l'agent a fait avant de pouvoir l'éditer en confiance.

L'expression dans la réponse était « Layout Understanding Layer ». C'est un bon nom car il refuse la réponse paresseuse. Le design agent-native ne peut pas signifier « faites confiance à la capture d'écran ». Il lui faut un modèle lisible de l'artefact : sections, intention, parties éditables, références stables et mouvements d'édition suggérés. Cet article est une tentative de prendre cette réponse au sérieux — d'esquisser ce qu'une telle couche pourrait porter, où elle devrait vivre dans Open Design, et pourquoi c'est un chemin de contribution plutôt qu'une promesse de roadmap.

Le canvas donnait aux designers une confiance spatiale

Le canvas de Figma n'est pas seulement une surface de dessin. C'est aussi une surface d'explication. Vous pouvez dézoomer, voir la hiérarchie de la page, cliquer sur un frame, inspecter les contraintes, renommer les calques, et comprendre où une partie du travail finit et où une autre commence.

Ce que vous perdez réellement quand le canvas disparaît

Cette compréhension est facile à sous-estimer jusqu'à ce qu'elle disparaisse. Une landing page générée peut paraître correcte dans un aperçu en bac à sable et rester difficile à diriger. Le problème n'est pas les pixels — c'est l'absence d'un vocabulaire partagé entre l'humain et l'agent.

« Rends le hero plus assuré » n'est utile que si l'agent et l'humain s'accordent sur ce qu'est le hero. « Resserre la section tarifs » ne fonctionne que si l'artefact porte une identité de section stable à travers les révisions. Sans cela, chaque instruction se dégrade en désignation : le designer décrit une région par sa position (« le deuxième bloc à partir du haut »), l'agent devine à partir de la sortie rendue, et la régénération suivante renumérote discrètement tout. Le canvas absorbait ce coût en silence. Il nommait les parties pour vous, gardait ces noms stables pendant que vous travailliez, et vous laissait en sélectionner une sans avoir à la décrire.

La clarté vaut la peine d'être conservée même si l'unité est mauvaise

C'est la partie de l'argument #DeFigma qui demande de la prudence. Le canvas est peut-être la mauvaise unité de travail pour un système agent-native — il suppose un humain faisant glisser des rectangles, pas un agent écrivant des fichiers — mais la clarté que les gens obtenaient du canvas reste précieuse. L'erreur serait de traiter « abandonner le canvas » et « abandonner la compréhension que le canvas apportait » comme la même décision. Ce n'en est pas une. Open Design doit déplacer cette clarté dans le modèle d'artefact, et non la jeter. La couche de mise en page est le nom de ce déplacement.

Open Design a déjà les bonnes primitives

La raison pour laquelle cette proposition convient à Open Design est que le projet est déjà construit autour de contrats explicites. Un skill est un fichier SKILL.md. Un design system est un fichier DESIGN.md. Un plugin ajoute un fichier d'accompagnement open-design.json. Rien dans le système n'est un blob binaire que vous devez désosser ; les contrats sont du texte, et le texte est quelque chose qu'un agent comme un humain peuvent lire. La mécanique est couverte dans 31 skills, 72 systems : comment fonctionne la bibliothèque Open Design, et l'argument produit se trouve dans Pourquoi nous avons conçu Open Design comme une couche de skills, pas un produit.

La couche de mise en page devrait suivre le même modèle. Elle devrait être du texte que l'agent peut lire, un état que l'UI peut rendre, et des métadonnées qu'un autre agent peut réutiliser. Si elle ne peut pas satisfaire les trois à la fois, c'est qu'elle a la mauvaise forme.

En termes de dépôt, cela pointe vers trois surfaces :

Surface	Ce qu'elle devrait porter
Manifeste d'artefact	IDs stables pour les sections, composants, actifs et fichiers générés
Instantané du plugin	Quel skill, design system, entrées et étapes de pipeline ont produit l'artefact
UI de revue / sortie headless	Une carte de mise en page, les aspects éditables et les intentions d'édition suggérées

La contrainte importante : la couche ne doit pas devenir un second canvas propriétaire. Le mode de défaillance à éviter est de reconstruire le graphe de scène de Figma sous un nouveau nom — une structure riche et spécifique à l'application que seule l'UI d'Open Design peut rendre et qui meurt dès que vous quittez l'application. La couche de mise en page devrait au contraire être une simple carte d'artefact qui voyage avec les fichiers, afin qu'un contributeur puisse la lire dans un éditeur de texte et qu'un autre agent puisse la consommer sans SDK.

Un squelette de mise en page filaire se soulevant comme sa propre couche sélectionnable au-dessus d'un canvas vierge, dans un cadre vert sur un fond éditorial presque blanc — La couche de mise en page est la structure que le canvas gardait implicite — extraite là où un agent et un humain peuvent tous deux la lire.

Une forme concrète pour la couche de mise en page

Voici la plus petite version qui rendrait le design agent-native moins opaque :

Chaque artefact généré reçoit des IDs sémantiques stables : hero, proof-strip, pricing, faq, final-cta.
Chaque ID porte une phrase d'intention : « Expliquer la promesse du produit en un écran », pas « section du haut ».
Chaque section liste les aspects éditables : texte, densité, mise en page, couleur, média, animation, source de données.
Chaque fichier généré renvoie à l'ID de section qui l'a produit.
Chaque passe de revue émet des intentions d'édition suggérées : « raccourcir le titre du hero », « augmenter le contraste dans les cartes de tarifs », « scinder le bloc de témoignages ».
L'UI rend cela comme un navigateur, tandis que les utilisateurs headless reçoivent la même structure en JSON ou en Markdown.

À quoi un manifeste pourrait réellement ressembler

L'intérêt de l'écrire est que la structure est banale — ce qui est précisément pourquoi elle peut être un contrat public plutôt qu'une astuce privée. Un manifeste pour une landing page générée pourrait se lire ainsi :

{
  "artifact": "landing/index.html",
  "producedBy": { "skill": "magazine-poster", "system": "linear", "stage": "compose" },
  "sections": [
    {
      "id": "hero",
      "intent": "Explain the product promise in one screen",
      "editable": ["copy", "density", "media"],
      "files": ["landing/index.html#hero", "landing/hero.css"]
    },
    {
      "id": "pricing",
      "intent": "Let a visitor self-select a plan without scrolling back",
      "editable": ["copy", "layout", "data-source"],
      "files": ["landing/index.html#pricing", "landing/pricing.json"]
    }
  ],
  "suggestedEdits": [
    { "target": "hero", "intent": "shorten headline to one line" },
    { "target": "pricing", "intent": "drop from three plans to two" }
  ]
}

Aucune de ces clés n'est exotique. sections est une liste, editable est une énumération, files est une référence arrière. La valeur ne réside pas dans l'astuce du schéma — elle réside dans le fait que les IDs survivent à une régénération, de sorte que le même bloc pricing reste pricing après que l'agent l'a réécrit deux fois.

C'est suffisant pour permettre à un designer de dire « Passe pricing de trois plans à deux », et suffisant pour permettre à un agent de code de patcher le bon fichier sans deviner à partir des pixels. L'instruction se résout en un ID de section, l'ID de section se résout en un ensemble de fichiers, et l'édition atterrit là où elle était censée.

Pourquoi c'est un chemin de contribution, pas une demande de fonctionnalité

Cela donne aussi à la communauté un chemin de contribution propre. Un contributeur n'a pas besoin de redéfinir le produit pour aider ici. Il peut écrire un skill qui émet un manifeste pour un type d'artefact, un atome de revue qui propose des intentions d'édition, une extension de manifeste qui ajoute un champ que d'autres skills peuvent lire, ou un cas de test qui vérifie que les IDs de section restent stables à travers une régénération. Chacune de ces contributions est un petit changement fusionnable qui rend une sortie moins opaque — et parce que la couche est en texte brut, deux contributeurs travaillant sur un deck et un écran mobile n'ont pas à coordonner un format binaire partagé. La couche de mise en page devient un contrat public, et non une capacité privée enfouie dans l'application.

Quoi faire ensuite

Si c'est le genre de problème sur lequel vous voulez travailler, contribuez un petit skill ou plugin qui rend un artefact plus facile à inspecter. Commencez par une sortie concrète : une landing page, un deck ou un écran mobile. Ajoutez des IDs de section stables, décrivez les aspects éditables, émettez-les en JSON ou en Markdown aux côtés de l'artefact, et ouvrez la PR avec un artefact avant/après pour qu'un relecteur puisse voir la différence qu'apporte une couche inspectable.

C'est encore une direction, pas une fonctionnalité livrée — l'intérêt de la nommer maintenant est que les primitives existent déjà, donc le travail est additif plutôt qu'une réécriture.

Contribuez un skill.

Lectures associées

31 skills, 72 systems : comment fonctionne la bibliothèque Open Design — les primitives actuelles pilotées par fichiers sous la proposition
Pourquoi nous avons conçu Open Design comme une couche de skills, pas un produit — la forme de produit qui rend possibles les contrats d'artefact publics
L'alternative open-source à Figma — où « abandonner le canvas » atterrit face à l'acteur en place qui a rendu le canvas central