Le contexte devient le goulot d'étranglement dans le développement assisté par IA. Pas la capacité du modèle. Les modèles s'améliorent assez vite pour ne plus être régulièrement la contrainte. Ce qui limite la qualité du code généré par IA, c'est la qualité du contexte que ces modèles reçoivent.

Pour les workflows Figma-vers-code, le contexte se présente sous deux formes fondamentalement différentes : le contexte pixel (captures d'écran, images rendues) et le contexte structuré (IR typé, tokens, relations sémantiques). Ce ne sont pas juste des formats différents pour la même information. Ce sont des catégories d'entrée différentes, avec des propriétés différentes, des caractéristiques de perte différentes, et des plafonds différents sur ce qu'un agent peut produire à partir d'elles.

L'industrie utilise encore largement le contexte pixel. C'est une erreur. figmascope exporte du contexte structuré — le bon input dès le départ.

Ce qu'est le contexte pixel

Le contexte pixel est toute représentation rastérisée d'un design : une capture d'écran exportée depuis Figma, un PNG depuis « Exporter le frame », un rendu depuis un outil de design. C'est ce que vous obtenez quand vous appuyez sur Cmd+Shift+4 au-dessus de votre canvas Figma.

Les LLM à capacité visuelle peuvent traiter le contexte pixel de manière impressionnante. Ils reconnaissent les patterns UI, identifient les régions de mise en page, infèrent les types de composants depuis l'apparence visuelle, et génèrent du code plausible depuis des images seules. Si vous avez utilisé Claude ou GPT-4V pour la conversion capture-vers-code, vous l'avez vu. Les sorties paraissent correctes plus souvent qu'on ne s'y attendrait.

Mais « paraît correct » et « est correct » ne sont pas la même chose, et l'écart entre eux est là où vivent la conformité au système de design, la fidélité aux tokens, l'identité des composants et la reproductibilité.

Ce qu'est le contexte structuré

Le contexte structuré est une représentation typée et lisible par machine qui préserve la sémantique du design : ce qu'est chaque élément, pas seulement à quoi il ressemble. Il inclut :

L'IR de figmascope est cela. Chaque nœud dans un JSON par écran a kind, name, absoluteBoundingBox, children, des fills résolus en références de tokens quand disponibles, des propriétés d'auto-layout si applicable, et componentId sur les instances. C'est l'arbre du design rendu explicite.

Le contexte pixel dit à un agent à quoi ressemble un design. Le contexte structuré lui dit ce que signifie un design. Un agent de code a besoin de sens pour écrire du code, pas d'apparence. L'apparence, c'est pour les tests visuels.

Ce qui se perd dans la direction pixel-vers-structuré

Le mode d'échec central du contexte pixel est la perte d'information irréversible. Quand Figma rend un frame en PNG, il abandonne exactement l'information qui importe le plus pour la génération de code :

L'arbre de calques s'effondre. Il n'y a plus de « groupe de trois éléments avec des espaces de 8px ». Il y a une région de pixels qui suggère un groupe. L'agent doit reconstruire la structure de l'arbre depuis des preuves visuelles, et la reconstruction est approximative. Elle sera incorrecte un certain pourcentage du temps. Ce pourcentage croît à mesure que les designs deviennent plus complexes.

Les liaisons de tokens disparaissent. L'arrière-plan orange qui mappe sur color/action/primary devient #FF6B00. L'agent génère une valeur hex codée en dur. Si votre couleur change jamais, ou si vous supportez le mode sombre, ou si vous avez besoin d'auditer l'utilisation des tokens, cette valeur codée en dur est une dette.

L'identité des composants est perdue. Quatre instances du même composant de carte sont quatre rectangles d'apparence similaire. L'agent peut générer un composant réutilisable ou quatre blocs similaires-mais-pas-identiques, selon combien de similarité structurelle il infère. Vous voulez une sortie prévisible ; vous obtenez une sortie probabiliste.

L'intention de mise en page est ambiguë. Est-ce un flex row ou une grille ? L'espacement entre les éléments est-il un gap, une marge ou du padding sur chaque élément ? Les pixels ne le disent pas. L'agent choisit. Les choix diffèrent entre les exécutions.

Le pipeline Figma → React, avec et sans structure

Considérez le chemin de Figma vers du React de production.

Avec le contexte pixel : Exporter PNG. Coller dans Claude. Obtenir du JSX. Réviser le JSX pour la justesse. Remarquer des valeurs codées en dur. Remarquer une mauvaise structure de composants. Prompter pour des corrections. Itérer. Finalement obtenir quelque chose de plausible. Modifier manuellement pour correspondre au système de design. Livrer. Prochain écran : recommencer de zéro parce que les sorties de l'exécution précédente ne se composent pas.

Avec le contexte structuré : Exporter le bundle (un clic, s'exécute dans le navigateur). Passer CONTEXT.md + l'IR d'écran à Claude avec votre prompt système spécifiant le framework et les conventions du système de design. Obtenir du JSX qui utilise vos noms de tokens, vos noms de composants, une structure de mise en page correcte. Réviser pour la justesse. Livrer. Prochain écran : même bundle, même agent, sorties composables parce que les entrées sont cohérentes.

Les économies de travail sont réelles mais secondaires. Le gain principal est la composabilité. Le contexte structuré permet des sorties qui se composent entre les écrans et les agents. Le contexte pixel ne le fait pas — la sortie de chaque écran est une île générée depuis un nouveau passage d'inférence.

Structure signifie : typé

Chaque nœud dans l'IR a un kind. Cela importe immédiatement. Un nœud TEXT génère un élément texte. Un FRAME avec auto-layout génère un conteneur. Une INSTANCE de Button/Primary/Large génère un appel de composant bouton avec les bonnes props. Un VECTOR génère une référence d'icône.

L'agent ne devine pas. Il mappe les types sur des primitives de code. Le mapping est spécifié dans CONTEXT.md pour le framework cible. « Pour les nœuds INSTANCE, utiliser le nom du composant pour déterminer le composant React. Pour FRAME avec layoutMode HORIZONTAL, utiliser un flex row. Pour TEXT avec le style typography/heading.lg, utiliser le composant Heading. » Ce sont des règles de style compilateur, pas des tâches d'inférence.

Structure signifie : spatial

L'absoluteBoundingBox sur chaque nœud donne la position et la taille dans l'espace de coordonnées Figma. Combiné avec les propriétés d'auto-layout — layoutMode, itemSpacing, paddingLeft/Right/Top/Bottom, primaryAxisAlignItems, counterAxisAlignItems — l'agent a tout ce dont il a besoin pour générer du code de mise en page correct sans compter les pixels.

Les boîtes englobantes absolues permettent aussi à l'agent de vérifier sa sortie : si un composant généré a des dimensions différentes de celles spécifiées dans l'IR, quelque chose s'est mal passé. C'est une propriété testable du contexte structuré qui n'a pas d'équivalent dans le contexte pixel.

Structure signifie : conscient de l'identité

Quand quatre nœuds dans l'IR partagent un componentId, l'agent sait qu'ils sont des instances du même composant. Il génère la définition du composant une fois, dérive les props depuis les variants dans les instances, et rend quatre appels. C'est la sortie correcte. Elle n'est pas réalisable depuis le contexte pixel sans une ingénierie de prompt significative qui demande essentiellement à l'agent de re-dériver la structure que le fichier de design avait déjà.

Les références croisées de chaînes fonctionnent de la même façon. Quand plusieurs nœuds texte référencent stringRef.key: "action.continue", l'agent sait utiliser une seule recherche i18n, pas trois chaînes codées en dur. L'information d'identité est dans l'IR ; l'agent la lit simplement.

Structure signifie : contrôlable par version

Les fichiers JSON simples diffent proprement. Une valeur de padding changée apparaît comme un changement d'une ligne dans l'IR par écran. Un token renommé apparaît comme un diff de recherche-remplacement dans le fichier de tokens. Une nouvelle instance de composant apparaît comme un objet ajouté dans le tableau des enfants.

C'est l'historique des versions de design qui est réellement utile pour les ingénieurs. Pas « le design a été mis à jour mardi » mais « voici les trois propriétés qui ont changé entre les exports v2 et v3 de cet écran ». Vous pouvez le mettre dans la description de votre PR. Vous pouvez faire des vérifications automatisées dessus. Vous pouvez l'utiliser pour auditer si le changement de code correspond au changement de design.

Où cela mène : infrastructure de contexte design

La catégorie d'outillage qui se forme ici n'est pas « export Figma, mais mieux ». C'est une nouvelle couche dans la stack : l'infrastructure de contexte design. Le travail de cette couche est de transformer la source de design (fichiers Figma, bibliothèques de composants, systèmes de tokens) en artefacts structurés, lisibles par les agents et versionnés qui alimentent la couche de génération de code.

Cette couche se situe entre l'outil de design et l'agent de code. Elle a des responsabilités qu'aucun des deux côtés ne possède actuellement : gestion des snapshots, extraction sémantique, résolution des tokens, inventaire des composants, indexation des chaînes cross-écrans, versionnement des bundles. Ce sont des préoccupations d'infrastructure, pas des préoccupations d'outil de design et pas des préoccupations LLM.

La traiter comme infrastructure signifie : elle est automatisée, elle est versionnée, elle s'exécute en CI, elle a un format défini, elle est inspectable. De la même façon qu'un système de build est une infrastructure pour le code — pas le code lui-même, pas le binaire cible, mais le pipeline fiable et reproductible qui convertit l'un en l'autre.

Honnêtement : les pixels comptent toujours

Les bundles figmascope incluent des PNG 2× de chaque écran exporté. Pas parce que le PNG pilote la génération de code, mais parce que la confirmation visuelle importe. Un agent devrait pouvoir faire une référence croisée de sa sortie générée avec le PNG. Un développeur devrait pouvoir regarder l'écran sans ouvrir Figma. Le PNG est une vérification de cohérence, pas une spécification.

Cette distinction — pixels pour la confirmation, structure pour la spécification — est le bon modèle mental. Vous n'éliminez pas le contexte pixel ; vous le rétrogradez à son rôle correct. C'est l'artefact QA, pas l'entrée de build.

De la même façon que vous ne donneriez pas à un compilateur une capture d'écran de votre code source : vous lui donnez la source, et vous utilisez des captures d'écran pour la documentation. Le fichier de design est la source. Le bundle est l'artefact de compilation. Le PNG est l'image de documentation.

Où cela mène pour la génération de code multi-cibles

Le contexte structuré permet un workflow que le contexte pixel ne peut pas : un design, plusieurs cibles. Le même IR peut alimenter un générateur React/Tailwind, un générateur Jetpack Compose, et un générateur SwiftUI. Le design sous-jacent est le même ; le contexte spécifique à la cible (primitives du framework, conventions de nommage, APIs de mise en page) vit dans CONTEXT.md, qui est généré par cible.

C'est la génération de code multi-cibles qui évolue vraiment. Vous exportez un bundle depuis le design. Vous exécutez trois agents avec trois fichiers CONTEXT.md différents. Vous obtenez trois implémentations structurellement équivalentes parce qu'elles ont été générées depuis le même IR, pas depuis trois passages d'inférence séparés sur trois captures d'écran.

Le goulot d'étranglement pour ce workflow n'est pas la capacité du modèle. C'est la qualité du contexte. Le contexte structuré est ce qui le rend possible.

Exportez votre bundle de contexte structuré depuis l'application principale figmascope, puis utilisez-le avec Cursor, Claude Code, ou Aider pour une génération d'UI multi-cibles et composable.