Le bouton existe déjà. Pourtant, un agent d'IA en crée un nouveau, avec sa propre couleur, des espacements différents et une variante supplémentaire. Sur la capture d'écran, la copie semble similaire. Dans le projet, en revanche, un second composant est apparu, qu'il faudrait désormais maintenir séparément. Le problème n'est pas seulement la compréhension de l'image, mais l'absence d'identité du composant.
Figma Code Connect relie les composants de design à leurs équivalents dans le code et rend ces relations exploitables pour Dev Mode et MCP. La documentation actuelle décrit ainsi une voie précise pour le contexte. Elle ne démontre aucune amélioration générale de la qualité ou des coûts. Notre question est la suivante : de quelles informations un agent a-t-il besoin pour réellement réutiliser le bouton existant ?
La variante est un contrat
Notre propre composant d'exemple s'appelle QuietButton. Il possède une apparence primaire et une apparence secondaire, ainsi qu'un état désactivé. La consigne n'est pas « Construisez quelque chose de similaire », mais « Utilisez ce composant dans une configuration autorisée ». Cela semble évident, mais exige une relation précise entre le design et le code.
Design: understated action button
Code: QuietButton
Allowed variant: secondary
Label: View details
State: enabledCette fiche est un schéma de mappage de notre cru, et non un fichier de configuration Code Connect. Elle rend visibles les endroits où un agent devrait sinon deviner. Une valeur à consonance similaire comme « quiet » n'est pas automatiquement un paramètre valide si le composant réel attend « secondary ».
Il en va de même pour le contenu et l'état. Un bouton atténué à des fins décoratives peut être implémenté différemment d'une commande réellement désactivée. L'impression visuelle seule ne suffit donc pas pour le mappage technique.
Un petit exemple réel vaut mieux qu'une longue description de style
En complément du mappage, fournissez à l'agent une utilisation existante. Pour un simple composant HTML, cela pourrait ressembler à ceci :
<button class="action action--secondary" type="button">
View details
</button>Les classes appartiennent à notre exemple. Les règles CSS qu'elles portent doivent être déterminées par votre propre projet. La valeur ajoutée tient au fait que l'agent n'est pas censé inventer d'abord une nouvelle structure. Il reçoit un point de départ concret avec des modifications limitées.
Un complément utile nomme ce qui doit être préservé : le même composant, des variantes valides, l'utilisation existante au clavier et la finalité réelle de l'action. Une vaste collection de matériaux aux exemples contradictoires pourrait être moins utile qu'un extrait court et à jour.
Des mappages obsolètes peuvent sembler très convaincants
Supposons que le projet renomme une propriété. L'ancien mappage reste compréhensible et soigneusement formaté. Pour l'agent, c'est un contexte plausible, mais techniquement faux. La connexion avec le code actuel doit donc elle aussi être maintenue.
Pour un examen pratique de ce dont vous disposez déjà, choisissez trois composants fréquemment utilisés. Notez une utilisation réelle de chacun et ses variantes autorisées. Comparez ces détails avec le code actuel avant de publier un nouveau mappage. Cet exercice proposé ne prétend pas qu'un examen du dépôt a déjà été effectué ni qu'une exécution d'IA a réussi.
Un contre-exemple affine le mappage : que doit-il se passer si le design demande une variante que le composant ne possède pas du tout ? Au lieu d'inventer discrètement un nouveau bouton, l'implémentation doit signaler cette lacune. Le contexte manquant devient alors une décision de conception délibérée, qui peut être prise dans le projet réel.
Les valeurs de marque complètent le composant, mais ne le remplacent pas
Si vous réutilisez un composant de page qui vous est propre dans KENJTEC, la fiche de marque de KENJTEC BrandStudio ai peut fournir des couleurs, des polices et des formes précises. Appliquez délibérément ces valeurs à l'exemple HTML/CSS existant au lieu de faire réinventer le composant à partir d'une simple image.
Vos propres HTML, CSS et JavaScript peuvent ensuite être préparés manuellement dans le mode développeur de KENJTEC WebSiteBuilder ai, affichés séparément dans l'aperçu et publiés en tant que code personnalisé. Cela ne signifie pas une importation automatique Code Connect ni un hébergement d'applications React. Le mappage reste dans votre flux de développement externe.
La leçon technique est transposable : un système de design ne se compose pas uniquement de formes similaires. Il a besoin de relations vérifiables entre les variantes visibles et les composants réels. Plus ces relations sont concrètes, moins un agent doit deviner et plus il est facile d'évaluer son résultat par rapport au projet existant.
Sources et état
Recherche et documentation à la date du 25 octobre 2026. Code Connect : introduction.
