Les agents de programmation savent produire une interface à partir d'une consigne. Le hic, c'est qu'ils ne savent pas, d'eux-mêmes, ce qui existe déjà chez vous : les composants en place, leurs API, ni les conventions de l'équipe. Sans ce contexte, ils peuvent réinventer un bouton qui existe, se tromper de propriété ou oublier des états basiques comme le chargement et les erreurs. À l'écran, le résultat peut avoir l'air « bon ». Mais derrière, ça finit souvent par ajouter de la dette de maintenance.
La bêta de Storybook 11 vise justement à réduire ce décalage : donner aux agents un accès structuré aux composants, à leur documentation et à leurs tests. La version introduit des skills, ajoute des outils en ligne de commande utilisables sans interface graphique, propose des histoires typées et renforce le support de plusieurs frameworks. Storybook annonce aussi un paquet plus léger (25 %) et, dans certains scénarios liés à la documentation, une livraison du contexte jusqu'à dix fois plus rapide.
Voici ce que ces changements peuvent apporter à une équipe produit, comment les intégrer concrètement à un flux de travail, et surtout ce qu'il vaut mieux vérifier avant de généraliser.
Pourquoi les agents ont besoin du contexte de Storybook
Un agent de code n'a pas tant de difficulté à écrire du JSX ou du CSS. Le vrai manque, c'est l'accès à des informations fiables sur le produit où il intervient. Il peut sortir une interface techniquement correcte, tout en ignorant qu'un composant équivalent existe déjà, qu'une propriété est déconseillée, ou qu'un état précis doit être représenté.
Et c'est exactement là que les composants, les histoires et les tests de Storybook prennent de la valeur. Ils ne servent pas seulement à montrer une bibliothèque d'UI aux développeurs : ils décrivent aussi les conventions et les comportements attendus par l'application. L'idée de Storybook 11 est d'amener ces informations jusqu'aux agents sous une forme directement exploitable, au lieu de les laisser « deviner » à partir de fichiers éparpillés.
D'un catalogue visuel à un contexte de travail
Dans une équipe, une histoire Storybook montre comment un composant se comporte selon les propriétés, les tailles ou les états. Sa documentation précise les valeurs acceptées et les contraintes d'usage. Les tests fonctionnels et d'accessibilité, eux, vérifient que l'interface ne se limite pas à « avoir l'air bien » : elle doit se comporter correctement.
Pris seuls, ces éléments sont utiles aux humains. Relier tout ça à un agent donne un cadre plus concret : retrouver le bon composant, consulter son API, créer une histoire adaptée, lancer les tests et préparer une revue.
Ce point compte particulièrement quand plusieurs équipes partagent un design system. Réutiliser un composant validé évite de multiplier des variantes presque identiques, qui finissent par exiger des corrections et des évolutions en parallèle (donc chères). Et, dans une organisation française ou européenne, ça peut aussi aider à garder une cohérence entre des parcours soumis à des exigences différentes : espace client, outil interne, interface de gestion, etc.
Ce que l'agent ne sait toujours pas
Un contexte mieux structuré ne remplace pas une décision produit. Storybook peut exposer des composants et des comportements documentés ; il ne peut pas, à lui seul, juger si une demande colle aux règles métier, si le parcours est compréhensible pour les utilisateurs, ou si une modification respecte les arbitrages de l'équipe.
Il faut donc garder deux questions en tête : l'agent a-t-il utilisé les bons éléments techniques ? Et la solution répond-elle vraiment au besoin ? Les outils Storybook améliorent la première. La seconde reste du ressort humain, surtout pour les interfaces sensibles, les données personnelles, ou tout ce qui touche aux droits des utilisateurs.
Ce que le CLI change pour les équipes
Storybook 11 ajoute une commande tools dans sa ligne de commande. Elle donne accès à Storybook sans interface graphique, pensée pour aider rapidement les agents à récupérer la documentation et le contexte. Et cette base peut servir à créer des skills, des outils ou des automatisations spécifiques à une équipe, au-delà des workflows fournis officiellement.
Quelques exemples :
npx storybook@next tools --help
npx storybook@next tools docs list
npx storybook@next tools docs show --id "your-component-id"
La première affiche l'aide, la deuxième liste les composants documentés, et la troisième demande les infos d'un composant précis. Pour une équipe, c'est utile pour des tâches ciblées : récupérer la documentation d'un élément avant de générer une page, ou vérifier les composants pertinents dans un processus automatisé.
Des performances à interpréter avec prudence
Le CLI peut se connecter à un serveur de développement existant lorsqu'un outil a besoin du navigateur. Quand ce n'est pas nécessaire, il peut éviter de démarrer ce serveur. Cette différence compte dans l'intégration continue, ou dans les projets où le démarrage complet de l'application ralentit chaque itération.
Storybook annonce aussi, sur de « grands projets » (comme ceux de Chromatic), une transmission des résultats de documentation « à froid » vers les agents jusqu'à dix fois plus rapide qu'avec Storybook 10. Attention : ce chiffre vise la livraison de documentation dans un contexte donné, pas la promesse d'accélérer tout le développement. Et même si Storybook mentionne un gain supplémentaire avec TypeScript 7.1 stabilisé, ça reste à confirmer sur vos usages.
Le paquet annoncé comme 25 % plus léger peut aider à l'installation et à réduire une partie du poids des dépendances. Là encore, l'impact dépend de votre configuration : nombre de frameworks, addons installés, scripts de compilation, environnement de dev. Le plus fiable reste de mesurer chez vous : temps de démarrage, génération de documentation, tests - avant et après migration - plutôt que de reprendre les chiffres de lancement tels quels.
Construire ses propres workflows
Le CLI sans interface ne sert pas uniquement aux agents. Il permet aussi de construire des automatisations plus prévisibles : par exemple un contrôle déclenché au moment d'une demande de fusion, ou un outil interne qui regroupe la documentation d'un ensemble de composants.
La règle pragmatique est simple : automatisez d'abord une étape répétitive et bien définie. Si votre équipe ne sait pas encore quels composants doivent être utilisés pour un parcours, transformer cette incertitude en script ne la fera pas disparaître. En revanche, si les règles existent déjà (et sont clarifiées), le CLI peut aider à les rendre accessibles et vérifiables à plusieurs endroits du cycle de développement.
Quels frameworks sont concernés et comment migrer
La bêta couvre les principaux frameworks supportés par Storybook : React, Vue, Angular, Web Components et Svelte. Les évolutions portent notamment sur l'extraction des métadonnées et sur la qualité des exemples de code générés. Sans ça, les agents n'ont pas grand-chose de solide sur les propriétés disponibles : ils finissent par se baser sur une lecture incomplète du code.
Des améliorations différentes selon le framework
Pour React, Storybook s'appuie sur react-component-meta, qui remplace react-docgen et react-docgen-typescript, avec une promesse de meilleures performances et une extraction plus précise. Pour Vue, vue-component-meta améliore aussi les métadonnées. Pour Nuxt, le travail est censé étendre cette logique aux projets concernés.
Côté Angular, le nouveau paquet @storybook/angular-vite est présenté comme une collaboration avec des contributeurs d'Analog.js et l'équipe Angular. L'objectif : gagner en vitesse, en qualité des métadonnées, et résoudre certains problèmes existants dans l'intégration Angular. Si vous utilisez Angular 21 ou une version plus récente, vérifiez les instructions de migration avant de toucher à votre configuration.
Pour les Web Components, Storybook ajoute une prise en charge des contrôles pour les slots, les événements et les variables CSS, à partir du manifeste d'éléments personnalisés (CEM). Storybook peut aussi calculer ce manifeste s'il n'est pas fourni, puis le mettre à jour après les changements de code. Pour Svelte (traité comme un framework « core » dans cette bêta), la prise en charge inclut Svelte 5 et SvelteKit 3, sans addon requis pour Svelte CSF, avec une intégration TypeScript retravaillée.
En pratique, la portée est assez claire : une meilleure extraction des API aide à la fois la documentation pour les développeurs et le contexte fourni aux agents. Mais il faut mesurer en fonction de vos versions, de vos conventions et des addons réellement présents dans votre dépôt.
CSF 4 et migration progressive
Storybook 11 introduit CSF 4 : une évolution du format des histoires qui ajoute une API de fabriques typée. L'objectif est de rendre les exemples plus ergonomiques et de détecter davantage d'erreurs au moment de la compilation. Les addons peuvent aussi étendre le système de types pour leurs paramètres et options de configuration.
La migration ne doit pas forcément être « tout ou rien ». CSF 3 reste pris en charge, et des codemods sont proposés pour convertir automatiquement des histoires existantes. Dans un dépôt avec plusieurs équipes, avancer par lots est souvent plus sûr.
Avant de migrer, faites une photo de l'existant : version de Storybook, framework, addons, nombre d'histoires, et les erreurs de test que vous connaissez déjà. Ensuite, lancez la mise à niveau sur une branche dédiée :
npx storybook@next upgradeLa commande applique les migrations automatisées et signale ce qui nécessite une intervention manuelle. Pour un projet neuf, la bêta peut être installée avec npm create storybook@next. Comme il s'agit d'une bêta, commencez par une branche ou un projet non critique. Vérifiez les changements incompatibles, vos scripts de test, et le rendu des composants avant d'en faire une référence.
Conclusion : tester avant de généraliser
Storybook 11 bêta propose une évolution logique : faire des composants, des histoires et des tests une source de contexte réutilisable par les agents de programmation. Les skills structurent la façon de travailler, le CLI facilite l'accès aux infos, et la revue rend le passage en humain plus simple. De plus, CSF 4 et les améliorations par framework cherchent à améliorer la qualité des métadonnées.
Le bénéfice le plus intéressant n'est pas « laisser l'IA écrire plus de code ». C'est réduire l'écart entre ce qu'elle génère et les conventions déjà validées par l'équipe. Mais ça dépend vraiment de la qualité de votre design system, de votre documentation, et de la manière dont vous faites les contrôles humains.
Commencez par un cas d'usage limité, regardez la réutilisation des composants, les défauts détectés et le temps de revue, puis décidez si le workflow mérite d'être étendu. Une expérimentation cadrée répondra souvent mieux à la question qu'une adoption immédiate de toute la bêta.
Comment les skills organisent le travail de l'agent
Les skills sont le cœur de Storybook 11. Ils décrivent des étapes que l'agent peut suivre pour travailler avec plus de cohérence. Le ui-workflow encadre la construction d'une interface avec les composants disponibles, la rédaction d'histoires, l'exécution des tests et la préparation d'une revue.
Autre skill : component-docs. Il aide l'agent à retrouver des composants existants et à consulter leurs API, leurs métadonnées, leur documentation et des exemples de code. L'intérêt pratique, c'est de chercher « avant d'écrire ». Au lieu de partir directement sur une génération rapide d'UI, l'agent commence par comprendre les conventions locales.
Un cycle en trois étapes : trouver, vérifier, présenter
Le flux proposé se tient assez simplement :
Pour les tests, la commande
storybook tools test runs'appuie sur Vitest. L'agent peut exécuter des tests sur certaines histoires ou sur le projet, regarder les échecs, corriger, puis relancer les vérifications. Pour la revue,storybook tools review createprépare un aperçu dans le navigateur. Le but est de rendre la relecture plus simple, sans obliger le développeur à reconstituer manuellement tout l'enchaînement d'écrans touchés.Ce cycle ne supprime pas la revue humaine. En revanche, il réduit le travail de préparation et rend certains défauts plus visibles avant la demande de validation. Le gain « temps » ne compte vraiment que si le résultat reste facile à contrôler.
Ce qu'il faut mesurer dans votre équipe
Commencez par un cas simple et limité. Par exemple : ajouter un état vide sur une page déjà couverte par Storybook. Ensuite, comparez le résultat de l'agent avec votre flux habituel : a-t-il réutilisé le bon composant ? Les histoires couvrent-elles les états importants ? Les tests détectent-ils les régressions ? Et surtout : la revue est-elle réellement plus rapide ?
Surveillez aussi les erreurs de l'agent. Un skill ne rattrape pas une documentation obsolète, ni des histoires qui ne reflètent plus votre application. Si vos exemples sont incomplets, l'agent risque de reproduire ces manques à plus grande échelle. En clair : le bénéfice dépend autant de la qualité du système existant que de celle des outils.
Enfin, vérifiez ce que l'agent peut lire et modifier. Dans un contexte soumis au RGPD, l'enjeu n'est pas que Storybook « transforme » automatiquement des données en données personnelles, mais que les outils d'IA utilisés dans le flux n'aient accès qu'aux informations nécessaires. Permissions, journaux, règles internes : gardez tout ça explicite.