Lors de mon stage chez Apiqa communication, j'ai observé d'autres développeurs utiliser ShadCN/UI sur un projet sur lequel je ne travaillais pas directement. Je voyais des composants soignés, cohérents, et je me demandais d'où ils venaient. Quand j'ai compris le principe, ma première réaction a été : « Mais c'est juste du copier-coller, non ? »
La vraie question était là. ShadCN/UI n'est pas une bibliothèque au sens classique du terme. On n'écrit pas npm install shadcn-ui et on n'importe pas des composants depuis un module externe. À la place, on utilise une CLI qui génère le code source des composants directement dans le projet, dans un dossier components/ui. Le code t'appartient dès le départ.
J'ai expérimenté ShadCN dans les premières versions de ce portfolio. Ce qui m'a frappé, c'est à quel point les composants sont lisibles et bien pensés. Ils sont construits sur Radix UI, une bibliothèque de primitives accessibles, et stylés avec Tailwind. Le résultat : des composants accessibles, personnalisables, et que tu peux modifier ligne par ligne sans te battre contre une abstraction opaque.
La force de cette approche, c'est la propriété du code. Avec MUI ou Chakra, si tu veux modifier le comportement d'un composant en profondeur, tu te retrouves souvent bloqué par le système de thèmes ou les overrides CSS. Avec ShadCN, tu ouvres simplement le fichier button.tsx et tu changes ce que tu veux.
La limite, c'est que ça demande de la discipline. Puisque chaque composant est dans ton projet, les mises à jour de ShadCN ne se propagent pas automatiquement. Tu dois les suivre manuellement. C'est un compromis conscient : tu gains en contrôle, tu perds en automatisation.
Ce que ShadCN m'a appris, au fond, c'est une façon de penser les composants : pas comme des boîtes noires à utiliser, mais comme du code à comprendre, adapter, et faire sien. C'est une philosophie que je trouve plus saine pour apprendre, même si elle demande plus d'efforts au départ.