Shadcn/ui bascule vers Base UI par défaut : l'impact pour vos projets React

Début juillet 2026, l'équipe de shadcn/ui a basculé la librairie de composants headless par défaut du projet : ce n'est plus Radix, mais Base UI, le nouveau projet porté par la même équipe qui a créé Radix. Un changement qui tient en une ligne de changelog, mais qui concerne directement tous les projets React construits avec shadcn/ui, c'est-à-dire un très grand nombre d'applications lancées ces trois dernières années.

On fait le point sur ce que ce changement modifie concrètement, sur ce que vous devez faire (ou surtout, ne pas faire) si vous avez déjà un projet en production, et sur l'outil de migration livré en même temps par l'équipe.

Un petit rappel avant d'aller plus loin

shadcn/ui n'est pas une librairie de composants classique installée en dépendance npm. Lancé en janvier 2023, l'outil fonctionne comme un générateur : la commande npx shadcn add copie le code source d'un composant (bouton, dialogue, menu déroulant) directement dans votre projet, que vous stylez ensuite avec Tailwind. Derrière chaque composant se cache une librairie headless : un socle qui gère l'accessibilité, la gestion du focus, les états et les interactions clavier, sans imposer aucun style visuel. Depuis le lancement, ce socle était Radix : des primitives non stylées, une API solide, éprouvée dans des millions d'applications.

Base UI, le nouveau venu qui n'en est pas vraiment un

Base UI est développé par la même équipe que Radix. Après avoir construit Radix une première fois, elle recommence, avec tout ce qu'elle a appris entre-temps. Le projet a été taggé en version bêta courant 2025, puis shadcn a ajouté un support complet en décembre 2025 (choix de la librairie dès la création du projet via npx shadcn create) et une documentation dédiée en janvier 2026. Aujourd'hui, Base UI est stable en version 1.6.0 et dépasse les 6 millions de téléchargements hebdomadaires, selon l'équipe shadcn/ui.

Ce qui change concrètement pour vous

Trois choses basculent avec cette mise à jour :

• npx shadcn init installe désormais Base UI par défaut sur un nouveau projet.
• shadcn create affiche Base UI en premier choix dans la liste proposée.
• Sur le site de documentation, les pages de composants s'ouvrent par défaut sur l'onglet Base UI (l'onglet Radix reste accessible en un clic).

Selon l'équipe shadcn/ui, ce choix suit un constat d'usage : les projets créés via shadcn create choisissent Base UI deux fois sur trois face à Radix. Autrement dit, la bascule officialise une tendance déjà installée chez les utilisateurs plutôt qu'elle ne l'impose.

Et si vous avez déjà un projet en Radix ?

Rien ne vous oblige à bouger. Radix n'est pas déprécié : chaque nouveau composant et chaque mise à jour continueront de sortir pour les deux librairies, sauf exception explicitement réservée à Base UI. Si votre CI ou vos scripts appellent shadcn init de façon non interactive en s'attendant à récupérer du Radix, il suffit d'ajouter un flag pour garder l'ancien comportement :

pnpm dlx shadcn init -b radix

Si vous maintenez un registry de composants interne (une collection réutilisable entre projets, par exemple), vous pouvez aussi épingler la librairie attendue avec une configuration registry:base. Sans cette configuration, un item de registry s'initialise désormais avec Base UI par défaut.

L'outil de migration : un skill, pas un codemod

Pour les équipes qui veulent quand même passer à Base UI, shadcn/ui fournit un skill de migration plutôt qu'un script automatique classique. Installation :

pnpm dlx skills add shadcn/ui

Puis, dans votre agent de code habituel (l'équipe cite Claude Code et Cursor, mais tout agent qui supporte les skills fonctionne), une simple instruction en langage naturel suffit : migrate accordion to base-ui.

Le choix d'un skill plutôt que d'un codemod n'est pas anodin. Un codemod traite bien le code que vous n'avez jamais touché, et casse sur celui que vous avez personnalisé (variants ajoutés, classes modifiées, props supplémentaires). Le skill, lui, s'appuie sur une connaissance détaillée de chaque renommage et de chaque changement de comportement entre les deux librairies, vérifiée à la main composant par composant. Il applique les changements mécaniques partout (par exemple, la prop asChild devient render dans Base UI), mais signale les différences de comportement au lieu de les corriger silencieusement à votre place.

La migration est progressive par défaut : vous pouvez migrer un seul composant, garder un projet qui build et se déploie à chaque étape, puis reprendre une semaine plus tard exactement là où vous vous étiez arrêté. L'état de la migration vit dans vos fichiers et votre historique git, pas dans une session d'agent qui disparaît en fermant l'onglet. Les deux librairies cohabitent pendant toute la transition.

Chaque migration de composant produit trois choses : du code typé et buildé avant d'être annoncé comme terminé, un rapport dans un dossier .migration/ à la racine du projet (ce qui a changé, ce qui a été laissé de côté, une checklist à vérifier à la main), et un commit dédié sur une branche, ce qui rend un retour arrière aussi simple qu'une suppression de branche. Sur ses propres tests, l'équipe shadcn/ui annonce une migration complète en environ 25 minutes sur un projet de plus de 60 composants (dont 36 en Radix), pour un coût d'environ 10 000 tokens par composant.

Notre lecture chez CZSyn

On voit cette bascule comme du bon sens produit plus que comme une révolution technique. shadcn/ui a toujours vendu une promesse simple : vous possédez le code, pas une dépendance externe qui décide à votre place. En refusant l'an dernier de remplacer purement et simplement Radix par Base UI, l'équipe a tenu cette promesse jusqu'au bout, y compris quand ça allait à l'encontre de son propre calendrier produit.

Pour une agence comme la nôtre, qui livre des interfaces sur-mesure à des clients français, la vraie bonne nouvelle n'est pas Base UI en tant que tel, c'est l'outil de migration. Un changement de socle headless touche l'accessibilité, le clavier, les états de focus : exactement les détails qui coûtent cher à re-tester à la main sur une application déjà en production. Disposer d'un rapport écrit par composant, avec une checklist de vérification humaine et un commit isolé, change la donne pour estimer sereinement ce genre de chantier chez un client.

Notre recommandation concrète : si vous démarrez un projet aujourd'hui, partez sur Base UI par défaut, c'est désormais le chemin le mieux entretenu. Si vous avez un projet en Radix qui tourne bien en production, ne migrez pas par principe. Gardez l'option en tête pour le jour où un besoin réel (un composant qui n'existe que côté Base UI, par exemple) justifiera le chantier, et abordez-le alors composant par composant, jamais d'un coup.

Sources primaires

• shadcn/ui, « Base UI as the Default », changelog officiel, juillet 2026.
• Documentation officielle shadcn/ui, ui.shadcn.com/docs.
• Base UI, documentation officielle, base-ui.com.
• Radix UI, documentation officielle, radix-ui.com.