Design system privé : v0 réutilise enfin vos composants

v0 peut désormais s’appuyer sur le design system privé que votre équipe a déjà financé : le prototype démarre avec les vrais composants, et non avec des copies que les développeurs devront remplacer ensuite. Vercel a ouvert ce chemin d’authentification à 17:00 UTC le 18 septembre 2026 : transmettez à v0 un NPM_TOKEN ou un NPM_RC via une variable d’environnement partagée Development ou Preview. Il peut alors installer le package sans révéler l’identifiant au modèle ni l’écrire dans le système de fichiers de la sandbox.

Le changement paraît mineur. Pas le passage de relais.

Un package npm privé est du JavaScript ou du TypeScript distribué par un registre qui vérifie les droits de téléchargement. Les équipes s’en servent pour leurs composants de design system, leurs tokens, leurs outils d’authentification, leurs wrappers analytics et leurs utilitaires internes.

Avant cette mise à jour, ce contrôle du registre interrompait net le workflow v0. Un package public s’installait normalement. Pour une bibliothèque de composants privée, il fallait contourner le problème, par exemple en téléversant une archive, ou laisser le prototype recréer des composants assez ressemblants pour la revue. Cette seconde option paraissait rapide pendant la démo, puis imposait tout un remplacement au moment d’intégrer le code au véritable dépôt.

Le nouveau fonctionnement de v0 repousse l’authentification à la frontière de la sandbox. Dans Vercel Sandbox, v0 exécute le gestionnaire de packages déjà utilisé par le dépôt. Lorsque la requête d’installation part vers le registre privé, Vercel injecte l’identifiant à la frontière réseau. Ni le modèle ni l’agent ne peuvent lire sa valeur, et celle-ci n’est pas inscrite dans un fichier .npmrc local.

La nuance est décisive : le package entre dans le build, pas le secret dans le prompt ou le système de fichiers.

Pouvoir accéder au package n’apprend pas pour autant à v0 comment utiliser votre système. Il peut récupérer un composant Button tout en choisissant la mauvaise variante, en oubliant un provider ou en passant à côté d’un wrapper de thème. Le package doit donc être accompagné d’une documentation à jour, d’exemples et d’une véritable application cliente. La méthode plus large présentée dans Comment fournir un design system aux agents de code reste valable : le code transmet les mécanismes reproductibles, les consignes apportent le discernement.

Le vrai coût à supprimer : le remplacement des composants

L’enjeu métier n’est pas d’installer un package plus vite. C’est de pouvoir supprimer une reconstruction complète entre la validation du prototype et son passage en production.

Quand v0 invente un composant ressemblant, le prototype et le produit n’ont plus la même identité. L’équipe d’ingénierie doit remplacer les imports, remapper les props, rétablir le contexte du thème, retester les états et expliquer pourquoi l’écran validé a changé. Si v0 part du vrai package, le passage de relais peut se concentrer sur la revue et les ajustements plutôt que sur la reconstruction.

Prenons une hypothèse de travail, et non un benchmark Vercel. Supposons qu’un prototype exigeait auparavant 4 heures de remplacement de composants. L’équipe valorise le temps d’ingénierie à $100 par heure. Si la configuration et la validation de l’identifiant prennent 1 heure, le gain modélisé atteint 3 heures, soit $300.

Cette économie n’est pas garantie. Un package mal configuré, un provider manquant ou des consignes d’utilisation trop faibles peuvent consommer les mêmes 3 heures ailleurs. Mesurez le diff du dépôt et le temps de correction sur l’un de vos composants, puis décidez à partir de ce résultat si le workflow mérite d’être conservé.

Les équipes qui n’utilisent que des packages publics ne sont pas concernées. Même constat pour celles qui produisent des écrans conceptuels jetables, sans jamais les intégrer à un dépôt. Cette évolution compte surtout lorsqu’un prototype v0 validé doit devenir un logiciel maintenu.

Quel accès pour connecter votre design system privé ?

La règle tient en une ligne : NPM_TOKEN pour les packages privés hébergés sur registry.npmjs.org, NPM_RC pour le routage. Ne configurez pas les deux par précaution. La documentation sur les dépendances privées précise que NPM_RC l’emporte lorsqu’ils coexistent ; une ancienne configuration personnalisée peut donc masquer un token npm pourtant valide.

Configurer uniquement les droits nécessaires

1. 1

   Choisissez un composant réel

   Commencez par un composant déjà utilisé dans le dépôt de production. Vous disposez ainsi d’un import connu, d’un rendu visuel de référence et d’un vrai passage de relais à examiner. Un package réservé à la démo prouve que l’authentification fonctionne, pas que le workflow supprime les reprises.

2. 2

   Créez la variable partagée

   Dans Vercel, sélectionnez l’équipe, ouvrez Settings, puis Environment Variables. Ajoutez NPM_TOKEN ou NPM_RC comme variable partagée et limitez-la à Development, à Preview ou aux deux. Marquez-la comme sensible.

   La documentation v0 exige un rôle Vercel Developer ou supérieur pour gérer ce réglage. Le token doit uniquement donner accès en lecture à tous les packages privés installés par le projet, sans droits plus larges que ne l’exige le registre.

3. 3

   Routez un registre personnalisé

   Pour GitHub Packages, Vercel fournit cette valeur NPM_RC pour l’exemple du scope @acme :

   @acme:registry=https://npm.pkg.github.com/
   //npm.pkg.github.com/:_authToken=${GITHUB_PACKAGES_TOKEN}

   Enregistrez GITHUB_PACKAGES_TOKEN dans une autre variable partagée. Lors de l’installation, NPM_RC peut développer les références ${VAR} et applique à la valeur référencée la même protection que pour l’identifiant. Pour JFrog Artifactory, utilisez l’URL du registre et la variable de token correspondantes.

4. 4

   Vérifiez l’intégration v0

   Dans v0, ouvrez Settings, puis Integrations, et repérez npm. v0 associe automatiquement les variables partagées prises en charge. Demandez-lui d’installer et d’afficher le composant choisi, puis vérifiez que la preview utilise les styles, le provider et le comportement attendus.

5. 5

   Contrôlez le passage vers le dépôt

   Envoyez le résultat dans le véritable dépôt. Examinez package.json, le lockfile, le chemin d’import, la configuration du provider, les styles globaux et le diff des sources. Lancez les vérifications déjà prévues par le dépôt. Une preview fonctionnelle est un indice utile, mais le passage de relais n’est terminé que si la branche continue d’utiliser proprement le composant validé.

Quatre équipes peuvent s’en servir dès demain

Une équipe SaaS qui construit un tableau de bord

Le designer produit peut prototyper un nouveau parcours de facturation avec exactement les composants privés déjà livrés par l’équipe frontend. Le bénéfice ne réside pas dans une génération plus esthétique, mais dans une validation portant sur le comportement réel de Button, Table et Modal, suivie d’un diff source plus réduit.

Un responsable design system qui prépare v0 pour l’entreprise

Le responsable peut ajouter le package privé avant un import Design Systems 2.0, puis fournir à v0 le dépôt source, une véritable application cliente et la documentation d’utilisation à jour. v0 crée une base de départ et attend la revue avant d’enregistrer le système. Le responsable peut ainsi corriger une seule fois les polices, providers, tokens et usages de composants obsolètes, avant que toutes les conversations suivantes en héritent.

Un responsable de plateforme en agence avec plusieurs registres

L’agence peut utiliser NPM_RC pour orienter les scopes de chaque organisation vers le bon registre, au lieu de copier un token dans chaque prototype. Elle obtient une configuration d’identifiants maîtrisée et moins d’imitations propres à chaque client. Des frontières d’accès distinctes et une procédure de revue restent toutefois nécessaires pour le package de chaque client.

Une équipe frontend d’entreprise sur GitHub Packages ou JFrog

L’équipe plateforme peut autoriser v0 à installer les mêmes dépendances internes que le dépôt importé. La preview devient plus fidèle : les erreurs de résolution des packages, de configuration du thème et d’import apparaissent pendant le prototypage plutôt qu’après le passage de relais. Si la politique interne interdit les identifiants partagés, la méthode .tgz documentée reste le pilote le plus limité.

Accès et prix : deux factures distinctes

La documentation sur les packages privés ne mentionne ni abonnement v0 payant précis ni option facturée séparément pour cette fonctionnalité. Elle impose en revanche une condition d’autorisation : la personne qui gère la variable partagée doit disposer d’un rôle Vercel Developer ou supérieur. La documentation des rôles Vercel réserve le rôle Developer au niveau de l’équipe aux offres Pro et Enterprise.

Cette condition est indépendante des offres v0 actuelles. Free coûte $0 par mois, inclut $5 de crédits mensuels et limite l’usage à 7 messages par jour. Plus coûte $30 par utilisateur et par mois, avec $30 de crédits mensuels par utilisateur et $2 de crédits quotidiens de connexion par utilisateur. Business coûte $100 par utilisateur et par mois, avec les mêmes montants de crédits annoncés et l’exclusion de l’entraînement activée par défaut. Enterprise est proposé sur mesure. L’ancienne offre Premium reste affichée à $20 par mois dans la documentation, mais elle est en cours de suppression et n’est plus proposée aux nouveaux utilisateurs.

Vercel Pro facture $20 de frais de plateforme mensuels, avec un siège autorisé à déployer et $20 de crédit d’utilisation mensuel. Chaque siège Owner ou Member supplémentaire coûte $20 par mois. Tous ces prix publics sont indiqués en dollars américains hors taxes.

À titre d’exemple, un siège v0 Plus et les frais de plateforme Vercel Pro totalisent $50 par mois hors taxes et consommation. Ce n’est pas le prix minimum de cette fonctionnalité. La documentation de la mise à jour n’indique pas que les deux offres payantes sont obligatoires : vérifiez donc votre compte et votre rôle actuels avant toute montée en gamme.

Les limites, sans détour

L’accès aux packages privés fait tomber un obstacle. Il ne transforme pas une bibliothèque de composants en design system complet, ne rend pas le code généré prêt pour la production et ne met pas automatiquement à jour un projet existant lorsque le package évolue.

Les limites concrètes restent les suivantes :

• Les Shared Environment Variables ne prennent pas en charge les valeurs propres à une branche.
• NPM_RC est prioritaire sur NPM_TOKEN lorsque les deux sont présents.
• Le token doit couvrir tous les packages privés installés par le projet, y compris les dépendances privées du package choisi.
• L’identifiant peut être protégé tandis que l’implémentation générée reste incorrecte.
• Providers, CSS global, polices, tokens, états des composants, tests, accessibilité et revue font toujours partie du passage de relais.

La promesse de sécurité est précise et utile : v0 n’expose l’identifiant ni au modèle ni à l’agent, et ne l’écrit pas dans le système de fichiers de la sandbox. Il revient toujours à votre entreprise de décider si un token de registre peut servir dans ce workflow, de limiter finement ses droits et d’organiser sa rotation.

Ce qu’il faut faire lundi

Passez à l’action cette semaine si votre équipe possède déjà un package de composants privé et si les prototypes v0 sont régulièrement destinés au dépôt. Attendez si le responsable de la sécurité n’a pas validé l’usage d’un identifiant de registre en lecture seule. Pour un pilote circonscrit sans partage d’identifiants, choisissez la méthode .tgz. Ignorez cette mise à jour si vous utilisez uniquement des packages publics ou si votre travail dans v0 s’arrête à des concepts jetables.

Lundi, importez un véritable composant privé. Placez l’identifiant en lecture seule le plus restreint possible dans Development, vérifiez l’intégration npm, demandez à v0 d’afficher le composant, puis transférez le résultat vers le dépôt. Contrôlez la dépendance, le lockfile, l’import, le provider, l’état visuel et le diff source. Si ce composant franchit le passage de relais sans être remplacé par une imitation, alors le workflow a réellement changé. Mesurez ensuite les heures gagnées avant de l’étendre.

Pour recevoir la prochaine évolution concrète des plateformes et son impact économique, inscrivez-vous à la newsletter.