Premier aperçu d'Astryx, le design system de Meta

Astryx est la reconstruction open source, par Meta, du design system qui a grandi au sein de l’entreprise. Annoncé sur le blog d’Astryx le 18 juin 2026 et publié en bêta publique sous licence MIT, il propose plus de 150 composants React accessibles, sept thèmes prêts à l’emploi, des templates et une CLI, le tout reposant sur React 19 ou une version ultérieure et sur StyleX.

Si vous avez déjà livré un projet avec MUI, vous connaissez une version du compromis : les composants fonctionnent, puis vous passez un sprint entier à vous battre avec un objet de thème pour qu’un bouton cesse de ressembler au bouton de quelqu’un d’autre. Si vous possédez le code source de shadcn/ui, vous connaissez l’autre version : quarante fichiers de composants dans votre dépôt, entièrement à vous, sans amont d’où récupérer un correctif de gestion du focus.

L’argument de Meta est qu’Astryx se situe entre les deux. La liste des fonctionnalités est facile à trouver ; ce qui détermine réellement le coût de son adoption, c’est l’échelle de personnalisation à cinq barreaux et l’endroit où votre équipe finira par s’installer sur cette échelle. Cet article couvre ce qu’est Astryx, comment l’installer et l’utiliser, le fonctionnement du theming, ce que chaque barreau de cette échelle vous coûte, et comment il se positionne face à shadcn/ui et Base UI.

Qu’est-ce qu’Astryx ?

Astryx est une bibliothèque de composants entourée de tout un système : des composants React typés livrés avec du CSS pré-compilé, auxquels s’ajoutent le theming au niveau de la marque, le mode sombre, des templates de pages et une CLI, le tout distribué sous la forme d’un unique ensemble de packages. L’article technique de Meta le présente comme la reconstruction open source d’un système ayant grandi en interne pendant huit ans, atteint plus de 13 000 produits, et dont environ la moitié des mises à jour provenait de la communauté de builders interne. Les styles sont écrits avec StyleX, le compilateur de Meta qui transforme des objets de style en CSS atomique et sans collision au moment du build — ce qui compte si votre objection au CSS-in-JS porte sur le coût à l’exécution : aucun moteur de style ne tourne dans le navigateur.

La CLI est le point d’entrée de la majorité du travail avec le projet, pour les humains comme pour les machines. Documentation des composants, design tokens, templates de pages, outils de theming et codemods de mise à niveau en sortent tous, que vous l’appeliez depuis un terminal, que vous lisiez sa sortie JSON typée ou que vous importiez ses fonctions ; les agents et les outils de build passent par la même API. La présentation du projet comme « AI-fluent » et prêt pour les agents relève du positionnement, pas d’un résultat mesuré : le banc d’évaluation décrit par Meta n’a fait l’objet d’aucune publication de résultats dans l’un ou l’autre des billets d’annonce.

Comment utilise-t-on concrètement Astryx ?

React 19 est le plancher : @astryxdesign/core déclare react et react-dom en 19.0.0 ou plus comme peer dependencies. C’est le premier filtre. Le second est la maturité : @astryxdesign/core est publié sur une ligne 0.x sur npm, et @astryxdesign/vega ainsi que @astryxdesign/charts ne livrent de vrais builds que sous le dist-tag @canary, leur tag latest pointant encore vers une version placeholder.

Installez le package core, un package de thème et la peer dependency StyleX, avec la CLI en dépendance de développement :

npm install @astryxdesign/core @astryxdesign/theme-neutral @stylexjs/stylex
npm install -D @astryxdesign/cli
npx @astryxdesign/cli init

L’étape init écrit l’index des composants d’Astryx dans votre AGENTS.md ou CLAUDE.md, ce que vous pouvez ignorer si aucun agent ne touche au dépôt. Sur le chemin simple, vous importez ensuite trois feuilles de style, dans l’ordre, et vous englobez l’application dans un theme provider :

@import '@astryxdesign/core/reset.css';
@import '@astryxdesign/core/astryx.css';
@import '@astryxdesign/theme-neutral/theme.css';

Selon le dépôt lui-même, c’est là toute l’installation : les trois imports, le provider, et aucune modification de votre chaîne de build. Le chemin avancé construit à partir des sources TypeScript et StyleX à l’aide de @astryxdesign/build, qui embarque les plugins Babel, PostCSS et Vite, de sorte que le bundler n’émette les styles que pour les composants que vous importez réellement. Meta chiffre ce chemin à environ un tiers de la feuille de style complète dans sa propre application de référence — une mesure effectuée sur leur code, pas une règle générale. Chaque composant provient de son propre sous-chemin plutôt que de la racine du package.

Theming : le comportement dans le système, l’apparence dans les tokens

Astryx partage les responsabilités en deux. Le comportement et l’accessibilité vivent dans la bibliothèque ; l’apparence vit dans une couche de tokens, si bien qu’une configuration de thème contient couleurs, typographie, rayons, espacements et animations, et que modifier une seule valeur restyle tous les composants qui la lisent sans que personne n’ouvre le code d’un composant. Les valeurs claires et sombres cohabitent dans le même thème plutôt que dans deux fichiers parallèles, et un thème peut être permuté à l’exécution ou compilé en feuille de style statique. Les thèmes vont aussi au-delà des variables CSS : ils peuvent surcharger des composants individuels et des parties de composants, et ajouter leurs propres variantes.

Sept thèmes prêts à l’emploi sont livrés avec le projet, et vous partez de l’un d’eux plutôt que de rien : theme list affiche ce qui est disponible, y compris les thèmes issus des intégrations installées, et theme add <slug> dépose celui que vous choisissez dans votre projet sous forme de code source modifiable. C’est le pari de conception en une phrase. Le designer possède un fichier de configuration, et personne n’a besoin de forker ou d’encapsuler un composant pour changer son apparence.

Le chemin de personnalisation graduelle

La personnalisation dans Astryx s’échelonne sur cinq barreaux : utiliser les composants tels quels, ajuster les tokens du thème, attacher des noms de classes, superposer votre propre CSS, et enfin extraire (swizzle) le code source d’un composant dans votre dépôt. Chaque barreau achète plus de contrôle et coûte plus de responsabilité. Les quatre premiers vous maintiennent sur le chemin de mise à niveau partagé ; le cinquième en retire définitivement le composant concerné.

Le swizzling est la porte à sens unique. Certains éléments internes ne sont tout simplement pas exposés par l’API publique — état privé, structure du DOM ou écouteurs d’événements hors de portée — et éjecter le code source est le seul moyen d’y accéder ; à partir de là, c’est vous qui maintenez le composant, pas la bibliothèque. La CLI éjecte le code source d’un composant et exécute les codemods de version avec astryx swizzle Button et astryx upgrade --apply :

npx @astryxdesign/cli swizzle Button

Utilisez la forme scopée pour les exécutions ponctuelles : tant que @astryxdesign/cli n’est pas une dépendance, npm résout un astryx nu vers un package sans rapport. Le réflexe utile avant d’adopter Astryx consiste à confronter vos deux ou trois composants les plus exigeants au barreau cinq : si la personnalisation dont vous avez besoin passe par les internes, intégrez dès le premier jour le coût de posséder ce code source.

Interopérabilité du styling : xstyle, className et Tailwind

Les composants Astryx acceptent à la fois une prop typée xstyle pour les surcharges StyleX et un simple className, ce qui leur permet de cohabiter avec Tailwind, les CSS Modules ou des feuilles de style classiques. Le même composant, de trois façons :

import * as stylex from '@stylexjs/stylex';
import {Button} from '@astryxdesign/core/Button';

const styles = stylex.create({
  save: {alignSelf: 'flex-end', marginBlockStart: 24},
});

// 1. As shipped
<Button label="Save" variant="primary" />;

// 2. Typed StyleX override, compiled at build time
<Button label="Save" variant="primary" xstyle={styles.save} />;

// 3. Plain className, no compiler involved
<Button label="Save" variant="primary" className="ml-auto mt-6" />;

Sur le chemin pré-compilé, la troisième option ne nécessite aucun outillage supplémentaire : StyleX est la façon dont Astryx écrit ses styles, pas quelque chose que vous devez configurer. Une condition s’applique néanmoins. Astryx charge ses feuilles de style dans des cascade layers, @layer reset pour le reset et @layer astryx-base pour les styles de composants, et les layers ne répondent pas à la spécificité : tout ce qui reste hors layer, ou placé dans un layer déclaré plus tard, l’emporte de toute façon. Un projet qui embarque déjà du CSS global, un ancien reset ou Tailwind doit donc définir lui-même l’ordre des layers et placer délibérément chaque feuille de style dans un layer.

Astryx face à shadcn/ui et Base UI : quelles différences ?

Meta positionne Astryx face à deux issues qu’il nomme dans son billet de lancement : adopter le design system d’une grande entreprise et hériter de sa marque, ou assembler des composants copiés-collés et gagner en liberté tout en renonçant à la cohérence partagée, aux correctifs amont et à un chemin de mise à niveau, l’accessibilité retombant par défaut sur votre équipe. C’est l’argumentaire de Meta pour son propre produit, et il vaut la peine de le confronter à ce que disent les alternatives d’elles-mêmes. shadcn/ui se décrit à l’inverse : non pas comme une bibliothèque à installer, mais comme un moyen de construire la vôtre, en vous remettant le code des composants à éditer directement. Posséder le code est la fonctionnalité, pas un effet de bord, comme le détaille notre analyse des raisons pour lesquelles les équipes passent à shadcn/ui. Base UI livre des composants et hooks React headless sans CSS propre : l’apparence du résultat relève entièrement de vous.

À lire comme des contraintes plutôt que des verdicts : Base UI vous donne un comportement accessible et aucune opinion, shadcn/ui vous donne le code source et la maintenance qui va avec, et Astryx vous donne un système thématisé duquel vous pouvez encore vous éjecter composant par composant. Le cinquième barreau d’Astryx aboutit à la position de shadcn/ui par un autre chemin : un composant à la fois, et seulement quand vous le décidez.

Les réserves sont claires. C’est une bêta publique en 0.x sans ligne stable, elle exige React 19, et c’est un projet mono-éditeur ; les discussions autour du lancement ont soulevé des questions de gouvernance et de maintenance à long terme qu’aucun élément public ne tranche. L’instabilité de la bêta n’est pas hypothétique : la version 0.6.0 casse quiconque appelle useStepperContext directement, en retirant les champs de compact layout de ce hook et en réduisant StepperContextValue à l’historique des transitions et à l’enregistrement des étapes. À l’inverse, la page communauté fait état d’un Discord officiel et d’issues GitHub triées chaque semaine.

Qui devrait essayer Astryx maintenant, et qui devrait attendre ?

Essayez-le dès maintenant si vous démarrez un outil interne ou un dashboard greenfield sur React 19, que vous voulez des composants accessibles sans les concevoir, et que vous avez un designer qui préférerait posséder des tokens plutôt que relire des pull requests CSS. Attendez si vous êtes en deçà de React 19, si vous maintenez un produit grand public où une version mineure 0.x modifiant la forme d’un contexte vous coûterait une release, ou si la gouvernance mono-éditeur est une question d’achat à laquelle vous ne pouvez pas encore répondre. Une voie intermédiaire utile consiste à cibler un seul parcours d’une application existante : feuilles de style pré-compilées, ordre @layer explicite, et un unique écran construit à partir de composants que vous auriez sinon écrits vous-même.

Ce qu’il faut évaluer, ce n’est pas le nombre de composants. C’est le barreau de l’échelle de personnalisation sur lequel vos exigences de design vont vous forcer, car c’est ce que vous paierez dans un an. Choisissez les deux composants sur lesquels votre produit ne peut pas transiger, exécutez npx @astryxdesign/cli component <Name> pour chacun d’eux, et voyez si les tokens et className vous y amènent avant l’éjection du code source.

FAQ

Quelle est la différence entre Astryx et StyleX ?

StyleX est le compilateur CSS-in-JS build-time de Meta, qui transforme des objets de style en CSS atomique et sans collision. Astryx est le design system de composants React dont les styles sont écrits avec lui. Astryx installe @stylexjs/stylex comme peer dependency, mais consommer les feuilles de style pré-compilées ne nécessite aucun plugin de build, aucun PostCSS et aucune configuration Babel. Seuls les builds depuis les sources tirent les plugins StyleX de @astryxdesign/build.

Astryx fonctionne-t-il avec Next.js, Vite ou une simple configuration CDN ?

Oui. Le README de @astryxdesign/core documente les configurations pour Next.js, Tailwind, Vite et CDN. Sur le chemin pré-compilé, vous importez le reset, la feuille de style des composants et une feuille de style de thème, puis vous englobez l'application dans un theme provider : aucun plugin de bundler n'entre en jeu. Construire à partir des sources TypeScript et StyleX exige en revanche les plugins Babel, PostCSS ou Vite livrés dans @astryxdesign/build.

Ai-je besoin de la CLI Astryx pour utiliser la bibliothèque ?

Non. Les composants et le CSS pré-compilé fonctionnent à partir des seuls packages installés, et la CLI est une dépendance de développement. Vous en avez besoin pour theme list et theme add, la documentation complète des composants, les templates, les codemods de mise à niveau et le swizzling. Exécuter astryx init écrit l'index des composants Astryx dans AGENTS.md ou CLAUDE.md, ce qui ne compte que si des agents IA travaillent dans le dépôt.

Les composants de graphiques d'Astryx sont-ils prêts pour la production ?

Non. @astryxdesign/vega, le wrapper Vega, et @astryxdesign/charts, la bibliothèque de graphiques basée sur d3, ne publient de vrais builds sur npm que sous le dist-tag canary ; leur tag latest pointe vers une version placeholder que npm vous déconseille d'installer. Le package expérimental @astryxdesign/lab, où atterrissent les nouveaux composants avant d'intégrer core, est publié de la même manière. Les graphiques se situent donc en retrait des packages core déjà en bêta 0.x et nécessitent leur propre plan de repli.