Astryx, le système de design React interne de Meta, passe en open source après huit ans

Le système de design le plus utilisé chez Meta est resté huit ans en interne. En juin, Meta l'a publié sur npm. Astryx, un système de design open source bâti sur React 19 et StyleX, est arrivé en bêta publique le 18 juin 2026 et a atteint la version 0.6.0 le 10 septembre. Le projet a suscité un nouvel intérêt le 13 septembre, lorsque InfoQ lui a consacré un portrait comme système de design React « prêt pour les agents ».

À lire aussi: L'action ServiceNow a perdu 27 % quand la peur de l'IA a gagné le logiciel · Cloudflare rachète Deno pour rendre Workers auto-hébergeable.

Cette formule est celle de Meta, et elle désigne la partie la plus intéressante de la publication. La documentation, les outils en ligne de commande et le serveur Model Context Protocol (MCP) qu'utilise un ingénieur humain sont aussi destinés à être lus par un agent de codage IA travaillant à ses côtés. Meta affirme que son système interne alimentait plus de 13 000 applications et qu'environ la moitié des mises à jour provenaient de la communauté de développeurs à l'intérieur de l'entreprise. Ces chiffres décrivent un usage interne, non une adoption dans le reste de l'écosystème React, et Meta les présente comme la fondation sur laquelle Astryx a été bâti, plutôt que comme une preuve d'attrait extérieur.

Ce que Meta a réellement mis en open source

Astryx se présente sous forme d'un ensemble de paquets npm. @astryxdesign/core contient les composants, le système de thèmes et les utilitaires. @astryxdesign/cli gère la documentation des composants, les modèles, l'échafaudage, les thèmes et les codemods. @astryxdesign/build ajoute des plugins de compilation pour les compilations depuis les sources StyleX. Sept thèmes prêts à l'emploi sont fournis sous le nom @astryxdesign/theme-* : neutral, butter, chocolate, matcha, stone, gothic et y2k.

La description de Meta elle-même avance un total de « plus de 150 composants accessibles », aux côtés d'un thème au niveau de la marque, d'un mode sombre, de modèles et d'une CLI, et le README du projet dit la même chose. La boîte à outils est publiée sous licence MIT. Tout n'est pas stable : le paquet expérimental lab n'est pas publié sur npm, et les paquets charts et vega ne sont disponibles que sous une étiquette canary.

Le modèle de consommation est délibérément léger. Les développeurs importent du CSS précompilé et des composants React typés, de sorte qu'aucun plugin de compilation, ni PostCSS ni Babel, n'est nécessaire, et les composants conservent la prise en charge native de className pour les équipes utilisant Tailwind, les modules CSS ou du CSS simple. Le thème passe par une couche de jetons configurée avec defineTheme, où couleurs, typographie, espacement, mouvement et rayon sont déclarés une fois et se propagent à chaque composant. Meta décrit un parcours de personnalisation progressif : utiliser un composant tel que livré, ajuster les jetons du thème, ajouter ses propres classes, intervenir avec son propre CSS, ou éjecter entièrement la source avec la commande swizzle de la CLI. Cette dernière étape confie le code à l'équipe qui l'éjecte, avec sa maintenance.

Pourquoi un système de design interne qui devient public compte

Les grandes entreprises de plateformes ouvrent leurs outils internes pour des raisons diverses, et le schéma est familier. React, StyleX et PyTorch ont tous commencé comme infrastructure d'entreprise avant de devenir des briques partagées de l'industrie. Les systèmes de design constituent un cas particulier parce qu'ils encodent le goût autant que le code. Une bibliothèque de composants qui définit le comportement des boutons, des tableaux et des formulaires dans des milliers de produits internes est une affirmation sur la façon dont une organisation construit ses logiciels, et cette affirmation peut être exportée.

Pour les équipes extérieures, l'attrait est simple. Un système de design coûte cher à construire et s'avère fastidieux à maintenir, et la plupart des organisations finissent par reconstruire le même sélecteur de date, le même tableau et le même formulaire projet après projet. Adopter un grand système éprouvé échange ce travail contre une dépendance et un ensemble de conventions. Le revers est le même que celui qui poursuit tout projet open source d'entreprise : la gouvernance. InfoQ a noté que certains développeurs sur Reddit ont exprimé des inquiétudes au sujet de la maintenance et de la gouvernance à long terme d'un cadre parrainé par Meta, une question légitime pour tout projet dont la feuille de route est en dernier ressort fixée par une seule entreprise.

Astryx arrive sur un terrain encombré. Il concurrence shadcn/ui, qui distribue la source des composants plutôt qu'un paquet ; Chakra UI, qui livre son propre ensemble de composants stylés ; et Storybook, qui développe ses propres outils destinés aux agents. L'argument distinctif ne réside pas dans les composants eux-mêmes, mais dans l'outillage qui les entoure.

Le pari de l'aptitude aux agents

L'argument de Meta est que les assistants d'IA écrivent plus de code d'interface utilisateur qu'auparavant, et qu'un système de design doit être lisible pour ces assistants plutôt que réadapté après coup. La documentation d'Astryx sur le travail avec l'IA expose comment cela est censé fonctionner.

Trois éléments s'en chargent :

• La CLI, disponible sous le nom astryx ou xds, affiche à la demande la documentation complète d'un composant. Son indicateur --dense retire les remplissages destinés aux humains pour produire une sortie plus courte adaptée à la fenêtre de contexte d'un modèle.
• Un serveur MCP, hébergé à https://astryx.atmeta.com/mcp, expose deux outils, search(query) pour découvrir des composants et des modèles, et get(name) pour récupérer la documentation complète avec les props et les exemples. Il fonctionne avec tout client compatible MCP, notamment Claude Code, Cursor et Copilot.
• Un fichier de contexte généré, produit par npx @astryxdesign/cli init --features agents, qui écrit un AGENTS.md (ou .cursorrules ou CLAUDE.md) enseignant à un agent les conventions du projet avant qu'il n'écrive du code.

Meta livre aussi ce qu'elle appelle des « vibe tests », un dispositif d'évaluation qui mesure la facilité avec laquelle les humains et l'IA peuvent construire avec le système, et dit s'en servir pour trancher les débats de design par les preuves. L'entreprise affirme que la même référence que lit un ingénieur est à la disposition d'un assistant, de sorte que les deux construisent face à la même API.

Les tests indépendants offrent un tableau contrasté mais instructif. LogRocket a confronté Astryx à Claude Code en août et l'a comparé à shadcn/ui. L'agent a commis quatre erreurs avec Astryx, toutes sur des noms de props erronés, toutes immédiatement détectées par TypeScript. Face à shadcn, il a commis une erreur confirmée, une hypothèse d'API obsolète que le modèle n'avait aucun moyen de vérifier. La conclusion de LogRocket était que le manifeste n'empêchait pas les erreurs, il les rendait peu coûteuses à détecter. La même analyse a relevé des aspérités pratiques : un paquet de thème annoncé dans le dépôt n'était pas encore sur npm, et le nombre de composants variait selon les supports, « plus de 90 dans le dépôt, plus de 150 dans la documentation de Meta, et 153 dans le manifeste ».

Notre façon de construire des logiciels change, et Astryx est conçu pour les personnes et les agents qui construisent à leurs côtés.

StyleX, et pourquoi vous n'y toucherez peut-être jamais

Sous le capot, Astryx met en forme ses composants avec StyleX, le compilateur CSS-in-JS à la compilation de Meta qui produit un CSS atomique déterministe et sans collision. C'est le même moteur que Meta utilise depuis des années et un choix naturel pour un système qui devait prendre en charge des milliers de produits aux marques très différentes.

Le détail compte moins pour les utilisateurs qu'il n'y paraît. Comme Astryx livre du CSS précompilé, une équipe n'a pas besoin d'adopter StyleX, de configurer un compilateur ni d'apprendre l'API de mise en forme. Les composants acceptent une prop xstyle pour les équipes qui veulent une mise en forme typée à la compilation, mais la voie par défaut consiste à importer du CSS et à utiliser de simples surcharges de className. Meta précise que StyleX est un détail d'implémentation de la bibliothèque plutôt qu'une exigence imposée à ceux qui l'utilisent. Le compromis est réel, cependant : une équipe qui veut la chaîne complète de compilation depuis les sources, pour n'inclure que les styles qu'elle utilise, assume l'outillage StyleX en conséquence.

Ce qui a changé dans la v0.6.0

La publication du 10 septembre est la nouveauté de la fenêtre. La version 0.6.0 a ajouté des règles de thème réactives, ce qui signifie qu'un thème peut désormais adapter les jetons, les styles de composants, la typographie, la couleur, le rayon et le mouvement à des largeurs de fenêtre nommées, à la précision du pointeur, aux préférences de contraste et de mouvement réduit. Les règles se compilent en CSS, de sorte que le navigateur s'adapte sans attendre JavaScript.

La version a aussi rendu adaptatifs les composants Selector et MultiSelector, de sorte qu'un même contrôle peut s'afficher comme une infobulle ancrée sur un écran large et comme une feuille inférieure dimensionnée pour le toucher sur un écran compact. Le thème neutre par défaut a été reconstruit autour d'une palette OKLCH, six modèles ont été ajoutés, et Meta a commencé à publier des fiches de spécification formelles pour les composants et les systèmes partagés comme fondation de la v1. Ces fiches définissent l'API publique d'un composant, ses exigences d'accessibilité, son anatomie et ses cibles de thème, et Meta affirme qu'elles donnent aux contributeurs humains comme aux agents un contrat stable auquel confronter l'implémentation.

Bêta veut dire bêta

Les réserves méritent d'être énoncées clairement. Astryx n'a que trois mois de vie publique, ce n'est pas un écosystème mûr, et l'étiquette bêta de Meta est exacte. L'API publique peut encore évoluer, et la version 0.6.0 a même nécessité un codemod parce que les props et états visuels sont passés de simples classes CSS à des attributs data-*. Les motifs, tutoriels et réponses Stack Overflow existants sont limités comparés aux bibliothèques plus anciennes. Le chiffre de 13 000 applications en dit long sur la confiance interne et rien sur le nombre d'équipes extérieures qui adopteront le système.

Il y a aussi la question de la dépendance. Construire sur Astryx signifie accepter la feuille de route de Meta pour une bibliothèque de composants qui concurrence des alternatives gouvernées par la communauté. Certains développeurs prennent déjà leurs précautions : InfoQ a relevé des portages de l'architecture de jetons et des spécifications de composants vers Svelte 5 et Flutter, et GitHub affiche environ 13 000 étoiles et 1 100 forks. L'intérêt est réel, mais les étoiles ne valent pas des déploiements en production.

Ce qu'il faut surveiller

Trois éléments décideront si Astryx compte au-delà de Meta. Le premier est la v1 et l'ampleur des changements d'API d'ici là. La valeur d'un système de design dépend de sa stabilité, et une bibliothèque qui ne cesse de rompre ses propres conventions coûte cher aux équipes qui l'utilisent. Le deuxième est l'adoption extérieure : les équipes externes traitent-elles Astryx comme une alternative sérieuse à shadcn/ui et Chakra, ou comme une implémentation de référence intéressante dont elles s'inspirent ? Le troisième est la diffusion de l'outillage pour agents. Si le serveur MCP, le manifeste JSON et les fichiers de contexte générés deviennent un socle attendu, Meta aura poussé toute la catégorie des systèmes de design à traiter les assistants d'IA comme des utilisateurs de premier ordre. S'ils restent une particularité d'Astryx, le pari paraîtra précoce plutôt que visionnaire. Au vu des éléments disponibles, l'outillage est la partie à surveiller.

Image de couverture : illustration de couverture d'Astryx (Astracat). Image : Meta/Astryx.