Les équipes logicielles ont passé des décennies à intégrer le déterminisme dans leurs chaînes d'outils. Fichiers de verrouillage pour les gestionnaires de paquets. Images de base épinglées pour les conteneurs. Builds reproductibles pour les artefacts compilés. Le principe est bien compris : les mêmes entrées doivent toujours produire les mêmes sorties, sur n'importe quelle machine, à n'importe quel moment.

La passation de design n'a jamais appliqué ce principe. Elle a été, par défaut, un processus fondamentalement humain et donc non déterministe. Un designer explique le design à un développeur. Le développeur l'interprète. L'interprétation varie selon la personne, le jour, la clarté du commentaire Zeplin. Vous ne pouvez pas rejouer ça. Vous ne pouvez pas le tester. Vous ne pouvez pas le différentier.

Dans un monde d'agents de codage IA, une passation non déterministe est désormais un problème d'ingénierie de première classe. figmascope y répond avec un bundle de contexte figé et portable.

Pourquoi les outils actuels sont non déterministes pour les agents

Zeplin et Avocode vous donnent des chiffres extraits de Figma — dimensions de calques, valeurs de couleur, tailles de police. Mais ils les servent sous forme d'UI navigable, pas d'artefact lisible par machine. Un agent pointé vers Zeplin doit naviguer dans une UI pour trouver les valeurs, ce qui est fragile, soumis à des limites de débit, et dépend de la façon dont les annotations ont été rédigées.

Le Dev Mode de Figma va plus loin : il vous donne des extraits de code générés en ligne depuis le design. Mais les extraits sont sans état — régénérés à la demande, non versionnés. Il n'y a pas de bundle que vous pouvez committer. Il n'y a pas de fichier que vous pouvez différentier. Si le designer met à jour le design, la vue Dev Mode se met à jour silencieusement. Vous ne savez pas quand le design sous-jacent a changé par rapport à ce que vous avez exporté en dernier.

Les captures d'écran sont le pire cas : données pures en pixels, entièrement non déterministes à analyser, produisant une inférence de structure différente à chaque fois.

Les connexions MCP en direct — outils qui donnent aux agents un accès API en temps réel au fichier Figma — sont non déterministes par définition. Le fichier change pendant que l'agent le lit. L'exécution de l'agent à 9h et son exécution à 14h voient des entrées différentes. Vous ne pouvez pas reproduire l'exécution de 9h car la source a changé.

Les agents sont des systèmes probabilistes. Leur donner des entrées non déterministes ne produit pas seulement de la variance — cela rend le système non testable. Vous ne pouvez pas déterminer si une mauvaise sortie est causée par le modèle, le prompt, ou le fait que quelqu'un a déplacé un calque entre deux exécutions.

Le bundle comme unité de compilation

Le bon modèle mental pour un export figmascope est un artefact de compilation. Tout comme un compilateur prend du code source et produit un binaire déterministe — même source, mêmes flags, même binaire — figmascope prend un état de fichier Figma et produit un bundle déterministe : même état de fichier, même bundle, à chaque fois.

Le bundle est un instantané figé. Il capture une version spécifique du design et sérialise chaque propriété pertinente : mise en page spatiale, identité des composants, liaisons de tokens, contenu des chaînes, hiérarchie. Une fois exporté, le bundle est immuable. Le fichier Figma peut changer ; le bundle non. Si vous voulez incorporer ces changements, vous réexportez et obtenez un nouveau bundle.

C'est le modèle de l'unité de compilation. Le fichier de design est la source. Le bundle est l'artefact. Les agents consomment des artefacts, pas des sources.

Quatre propriétés d'une passation déterministe

Capturable en instantané. L'artefact de passation doit représenter un moment précis dans le temps. Pas « l'état actuel du fichier Figma » — un export nommé et versionné. Les bundles figmascope portent un _meta.json avec un horodatage d'export et une empreinte de ce qui a été inclus. Le bundle est un instantané, pas une vue en direct.

Portable. L'artefact doit être autonome. Pas de dépendances vers des services externes, des API en direct, ou des sessions authentifiées. Un bundle figmascope est un ZIP de fichiers simples — JSON, Markdown, PNG. Vous pouvez le copier, l'envoyer par e-mail, le committer dans git, le joindre à une PR, le remettre à un développeur junior ou à un agent de codage sans aucune configuration.

Inspectable. Un artefact déterministe est inutile si vous ne pouvez pas vérifier ce qu'il contient. Chaque fichier du bundle est lisible par un humain. CONTEXT.md est du Markdown. tokens.json a une structure proche du W3C. L'IR par écran est du JSON avec des noms de champs clairs. Un ingénieur peut ouvrir le bundle et auditer exactement ce qu'on a dit à l'agent. C'est qualitativement différent de « j'ai collé la capture d'écran et obtenu du code ».

Reproductible. Étant donné le même état de fichier Figma, deux exports séparés devraient produire des bundles fonctionnellement équivalents. Pas identiques byte-par-byte (les horodatages diffèrent), mais sémantiquement identiques : mêmes structures de nœuds, mêmes valeurs de tokens, même inventaire de composants. Si vous exportez deux fois depuis un fichier inchangé et que les bundles diffèrent sémantiquement, quelque chose ne va pas. Cette propriété vous permet de valider votre pipeline d'export et de détecter les régressions dans l'extracteur lui-même.

Comment cela se concrétise en pratique

Un designer termine un sprint d'écrans. Il exporte un bundle. Le bundle est commité dans le dépôt aux côtés du ticket — ou attaché au problème Jira, ou déposé dans le dossier partagé, selon votre workflow. À ce stade, l'artefact de passation est figé. L'agent (ou le développeur) travaille depuis le bundle, pas depuis le fichier Figma en direct.

En milieu d'implémentation, le designer met à jour trois écrans. Pas de problème : le bundle de travail du développeur est inchangé. Les nouveaux écrans obtiennent un nouvel export. Vous avez maintenant deux bundles et vous pouvez les différentier : qu'est-ce qui a changé entre le design avec lequel le développeur a commencé et le design actuel. C'est exactement le type de visibilité des changements qui est impossible avec les workflows basés sur des captures d'écran ou des connexions en direct.

Dans un workflow multi-agents — un agent construit la bibliothèque de composants, un autre construit les mises en page d'écran, un troisième écrit les tests — chaque agent reçoit le même bundle comme source de vérité. Ils travaillent tous depuis le même état de design figé. Leurs sorties sont composables car leurs entrées sont partagées et fixées. C'est la précondition pour une génération d'UI multi-agents qui soit réellement fiable.

Différentiation des bundles

Comme le bundle est constitué de fichiers simples, il se différentie comme du code. Deux exports du même fichier entre deux versions Figma vous donnent un diff JSON qui vous indique exactement ce qui a changé :

C'est une visibilité des changements de design qui n'existe dans aucun outil de passation actuel. Figma a son propre historique de versions, mais il est visuel et destiné aux designers. Un diff de bundle est structuré et destiné aux développeurs : données de changement lisibles par machine qui peuvent piloter des tests automatisés, mettre à jour des changelogs, ou déclencher des workflows CI.

CI/CD pour la passation de design

Une fois la passation déterministe, CI/CD suit naturellement. Vous pouvez écrire des tests qui s'exécutent sur un bundle : « cet écran doit inclure un composant Button/Primary », « ce token doit être lié et non une valeur codée en dur », « cette chaîne doit avoir une clé stringRef ». Ce sont des vérifications d'analyse statique sur des données structurées. Elles s'exécutent en millisecondes. Elles s'exécutent dans un pipeline.

Vous pouvez également valider la sortie de l'agent de génération de code par rapport au bundle qu'il a reçu. L'agent a-t-il utilisé les tokens ou des valeurs littérales codées en dur ? A-t-il généré le bon nombre d'instances du composant répété ? A-t-il utilisé les bonnes valeurs d'espacement ? Ces questions sont répondables quand la source de vérité est un fichier structuré, pas un PNG.

La comparaison avec MCP

Les connexions en direct de type MCP vers Figma gagnent du terrain. L'attrait est évident : l'agent voit toujours le dernier design, pas d'étape d'export, pas de gestion manuelle du bundle. Mais les connexions en direct échangent le déterminisme contre la commodité — et pour les agents IA, cet échange est mauvais.

Les connexions en direct signifient : le contexte de l'agent dépend du moment où il s'exécute. Une exécution à 9h et une exécution à 14h voient des données différentes si le designer a travaillé pendant la journée. Vous ne pouvez pas reproduire l'exécution précédente. Vous ne pouvez pas tester sur une entrée fixe. Vous ne pouvez pas auditer ce qu'on a dit à l'agent. Si le code généré est incorrect, vous ne pouvez pas distinguer « le modèle a fait une mauvaise inférence » de « le design a changé sous l'agent ».

Le bon modèle est : connexions en direct pour l'exploration et l'itération de design (où la fraîcheur importe), bundles déterministes pour la passation et la génération (où la reproductibilité importe). Ils ne sont pas en concurrence — ils opèrent à différents points du workflow.

Passer à un développeur junior

Les mêmes propriétés qui rendent les bundles bons pour les agents IA les rendent bons pour les développeurs humains qui sont nouveaux dans une base de code. Un développeur junior auquel on remet un bundle dispose de : la spec complète dans CONTEXT.md, toutes les valeurs de tokens dans tokens.json, chaque composant listé avec ses propriétés, chaque chaîne avec son identité. Il n'a pas besoin d'être dans le fichier Figma. Il n'a pas besoin d'un compte Figma. Il n'a pas besoin de savoir quel écran est l'autorité.

Le bundle est un bon de travail complet et autonome. Identique à ce que recevrait un agent. La seule différence est que l'humain le lit et que l'agent le traite de manière programmatique — mais l'artefact est identique.

Cette unification — même artefact, consommateur humain ou agent — est le point essentiel. Le bundle est l'unité de passation. Tout le reste est un détail d'implémentation.

Voyez la passation déterministe en pratique avec Claude Code, Cursor, ou Aider. Tous partent du même export figmascope.