La profondeur d'un CMS structuré, le confort éditorial d'un page builder. Arrive bientôt.
Les développeurs définissent un type de contenu dans un fichier .story. Le Studio s'y appuie pour l'affichage, le SDK TypeScript pour les types, le site en production pour ses requêtes. Rien ne dérive — ce que le dev construit, c'est exactement ce que l'éditeur manipule, et exactement ce qui part en ligne.
La plupart des CMS headless opposent confort d'édition et profondeur du schéma — Storystick refuse de choisir. En se concentrant sur les sites marketing, le schéma reste profond sans que le Studio devienne abstrait : des previews fidèles au rendu réel, des widgets fermés, et en dessous, une structure sur laquelle les devs peuvent s'appuyer.
Un agent rédige dans le Studio ; un humain relit, ajuste, valide. Dans toute équipe qui tient la route, quelqu'un reste dans la boucle — ce n'est pas une friction, c'est comme ça qu'on livre. Storystick est fait pour cette collaboration, main dans la main.
Composez vos pages à partir de blocs, prévisualisez en direct, publiez l'esprit tranquille.
Un hero, puis des features, puis un CTA. Glissez, réordonnez, changez de variante. Pas de templates à combattre, pas de « c'est un bloc, ou une page ? ».
Preview en direct, à côté de l'éditeur. Chaque mot apparaît dans la mise en page. Plus besoin de sauvegarder puis rafraîchir, plus de cache à vider.
Un blog, une landing page, un portfolio. La structure est prête — à vous les mots et les images.
Votre CTA est présent sur 40 pages. Modifiez-le ici — il change partout, d'un coup. Footer, grille de tarifs, témoignage : même mécanique.
Deux états, clairement affichés : En ligne et Modifications en attente. Le site ne bouge pas tant que vous n'avez pas cliqué sur Publier. Retour en arrière en un clic.
Demandez une nouvelle page produit, une traduction, une réécriture. L'IA rédige dans votre Studio, en respectant votre structure. Vous relisez, vous publiez.
Pour lier un auteur ou un cas client : vraies miniatures, vrais statuts, vraie recherche. Le bon choix du premier coup. Alerte avant toute suppression d'un contenu encore référencé.
Tags, FAQ, grilles de prix, blocs SEO — tout se ressemble et se comporte pareil sur l'ensemble de vos projets. Pas de plugin qui casse l'éditeur un mardi matin.
Schémas dans votre repo git, backend managé, Studio hébergé, TypeScript de bout en bout.
npx storystick init crée une app Next.js, provisionne votre backend, génère vos types TypeScript, et votre client obtient un accès au Studio hébergé, avec son projet prêt à storystick.app/p/votre-client-a3k9m2x7. À la fin de votre appel de découverte, il est connecté.
Fichiers .story dans votre repo, relus en PR comme n'importe quel code. Contenu stocké sur notre infrastructure managée, édité via le Studio hébergé. Séparation nette entre équipe dev et équipe édition.
Pas de Studio à garder en ligne, pas de CORS à configurer, pas de dépendances npm à chasser, pas de clés d'auth à renouveler. Une seule variable d'env dans votre app : STORYSTICK_PROJECT_ID=a3k9m2x7. Voilà, c'est tout le boulot d'ops.
storystick generate produit d'abord vos types. Query builder, props de slice, cibles de référence — tout est typé, tout suit votre schéma. Pas de any, pas de codegen en retard, pas de dérive.
Vous livrez les briques en composants React avec props. Les éditeurs assemblent les pages. Un seul <SliceZone />, un seul registre — le même qui alimente vos embeds RichText.
Chaque requête est une souscription. La cohérence en preview est automatique — y compris à travers les références. Un seul modèle mental pour le dev et la prod, pas deux.
@storystick/core, /client, /react, /next, /ui, /backend. Parser, query builder, SliceZone, Draft Mode, bibliothèque de composants — conçus pour fonctionner ensemble.
La signature du SDK, les messages d'erreur, l'introspection du schéma — pensés pour que les agents de code réussissent du premier coup. Idem pour MCP : les assistants IA de vos clients écrivent avec les mêmes mutations que le Studio.
Tout ce que fait un CMS headless classique — modélisation, previews, références, publication, SDK typé — Storystick le fait, en mieux, parce qu'il est pensé pour une seule chose : les sites marketing. Cette concentration le rend plus précis que les alternatives génériques. Si c'est tout ce que vous cherchez, c'est déjà une raison suffisante.
Mais ce n'est pas là que l'histoire s'arrête. C'est là qu'elle commence.
La façon dont on fabrique les sites web change plus vite que les outils censés les servir. Les sites ne sont plus codés à la main depuis zéro — ils sont générés, itérés et maintenus par des agents IA au service d'équipes qui n'ont aucune envie d'apprendre un CMS. « Mets à jour le hero de notre page pricing » devient une phrase qu'un agent transforme en mutation sûre — plus un ticket de support à l'agence qui a livré le site il y a six mois.
Mais les agents ne remplacent pas les personnes qui possèdent le contenu — ils travaillent à leurs côtés. Dans toute équipe d'une certaine taille, il y aura toujours un humain pour relire le brouillon, valider une modification, signer avant la mise en ligne. Ce n'est pas un goulot — c'est ainsi que les équipes sérieuses livrent, et ça ne va pas disparaître. La catégorie est sur le point de se scinder entre les outils qui greffent l'IA par-dessus, et ceux où humains et agents opèrent sur le même contenu, avec les mêmes garde-fous, main dans la main. Nous avons construit Storystick pour le deuxième camp.
Le fichier .story est ce qui rend ça possible : un seul artefact que vos développeurs écrivent, que le Studio de votre client rend, que votre TypeScript consomme, et sur lequel vos agents IA opèrent — avec les mêmes garanties sur les quatre surfaces. Rien d'autre dans la catégorie n'est pensé comme ça, et ce n'est pas un hasard. C'est précisément le propos.
Choisissez Storystick aujourd'hui parce que c'est un meilleur CMS headless pour les sites marketing. Mais comprenez ce que vous choisissez vraiment : une fondation pensée pour la production web telle qu'elle est en train de devenir — aux mains de l'agence, étendue par l'IA, sûre pour le client. Les sites que vous livrez dessus seront plus simples à construire aujourd'hui, et ils resteront les vôtres à piloter longtemps après que les outils d'à côté auront changé.