Storyblok CMS : Guide complet pour les développeurs [2026]

Storyblok est l'un des rares CMS headless où vos équipes éditoriales voient réellement ce qu'elles sont en train de modifier — et cette seule fonctionnalité change totalement la dynamique entre développeurs et éditeurs de contenu. Après une levée de fonds de 80 M$ en Série C et le lancement de l'automatisation des workflows en mars 2026, il vaut la peine de comprendre ce que Storyblok fait vraiment bien, ses limites, et s'il convient à votre prochain projet.

Qu'est-ce que Storyblok ?

Storyblok est un CMS headless avec un éditeur visuel intégré, fondé en 2017 à Linz, en Autriche, par Dominik Angerer (PDG) et Alexander Feiglstorfer (CTO). Il repose sur une architecture basée sur des composants appelés Bloks et délivre le contenu via des API REST et GraphQL. Utilisé par Adidas, Tesla et Oatly, Storyblok a levé 138 M$ au total, dont lors de son tour de Série C.

Un CMS headless sépare votre contenu de votre frontend : vous gérez le contenu via une API, et votre application React, Vue ou Astro le consomme. C'est la même chose avec Contentful, Sanity, Strapi et toutes les autres solutions headless. Ce qui distingue Storyblok, c'est l'éditeur visuel.

Nous gérons quatre sites en production sur différents CMS headless (dont Sanity, qui propulse ce blog). Voici ce que donne Storyblok sur la base d'une expérience concrète : l'éditeur visuel réduit vraiment les allers-retours entre développeurs et équipes éditoriales. Au lieu de remplir des formulaires et de demander "à quoi ça va ressembler ?", les éditeurs voient directement la page. C'est une vraie amélioration du workflow, pas un argument marketing.

L'architecture centrale repose sur deux concepts : les Stories (vos pages ou entrées de contenu) et les Bloks (composants réutilisables comme des sections hero, des grilles de fonctionnalités ou des CTA). Les développeurs définissent les schémas des Bloks, les éditeurs les glissent-déposent dans les Stories. Le contenu atteint votre frontend via la Content Delivery API.

Parmi les clients notables, on trouve au-delà d'Adidas et Tesla : Virgin Media O2, dm-drogerie markt, Oatly, Spendesk et Panini. Pour une vue d'ensemble de Storyblok face aux autres options, consultez notre comparatif CMS headless.

Comment fonctionne l'éditeur visuel de Storyblok ?

L'éditeur visuel de Storyblok charge votre frontend dans une iframe et superpose des zones éditables sur chaque composant. Les éditeurs voient un aperçu en direct exactement tel que le verront les visiteurs, avec la possibilité de cliquer directement sur chaque Blok pour le modifier. Cela nécessite la bibliothèque JavaScript StoryblokBridge dans votre application frontend.

C'est la fonctionnalité qui distingue Storyblok de l'approche formulaire de Contentful, de l'approche schéma-en-code de Sanity ou du panneau d'administration de Strapi. Ces CMS donnent aux éditeurs un formulaire avec des champs. Storyblok leur donne la page elle-même.

L'architecture iframe

Voici comment ça fonctionne en coulisses : quand un éditeur ouvre une Story dans le tableau de bord Storyblok, l'éditeur visuel charge votre application frontend dans une iframe. Storyblok injecte une propriété _editable dans les données de chaque Blok (uniquement sur le contenu en brouillon), et la bibliothèque JavaScript StoryblokBridge écoute les changements. Quand un éditeur clique sur un composant, le bridge communique avec la fenêtre parente Storyblok pour ouvrir le bon éditeur de champs.

Résultat : les éditeurs cliquent directement sur une section hero pour modifier le titre. Ils glissent un nouveau Blok de témoignage sous la section de tarification. Ils voient les changements se refléter instantanément dans l'aperçu. Fini le cycle "sauvegarder et vérifier sur le site de staging".

Un point à noter : l'éditeur visuel fonctionne uniquement avec le contenu en brouillon, pas avec le contenu publié. Votre URL de prévisualisation doit pointer vers une version de votre application qui récupère les données en brouillon. Beaucoup de développeurs se font surprendre par ça lors de la configuration initiale.

Configurer StoryblokBridge

Voici une configuration typique dans un projet Next.js App Router. Vous aurez besoin de @storyblok/react installé :

// app/components/StoryblokProvider.js
"use client";

import { storyblokInit, apiPlugin } from "@storyblok/react/rsc";
import Hero from "./bloks/Hero";
import FeatureGrid from "./bloks/FeatureGrid";
import CallToAction from "./bloks/CallToAction";

storyblokInit({
  accessToken: process.env.NEXT_PUBLIC_STORYBLOK_TOKEN,
  use: [apiPlugin],
  components: {
    hero: Hero,
    feature_grid: FeatureGrid,
    call_to_action: CallToAction,
  },
});

export default function StoryblokProvider({ children }) {
  return children;
}

Enveloppez ensuite votre layout avec le provider et utilisez le composant StoryblokStory pour activer l'édition en direct :

// app/[...slug]/page.js
import { StoryblokStory } from "@storyblok/react/rsc";
import { fetchStory } from "@/lib/storyblok";

export default async function Page({ params }) {
  const story = await fetchStory(params.slug?.join("/") || "home");

  return <StoryblokStory story={story} />;
}

Le composant StoryblokStory gère automatiquement la connexion au bridge — il enregistre l'écouteur iframe, applique les attributs _editable à vos Bloks et active le clic-pour-éditer dans l'éditeur visuel. Pas besoin de le câbler manuellement.

L'architecture par composants de Storyblok (Bloks et Stories)

Storyblok organise le contenu à partir de deux concepts fondamentaux : les Stories (pages ou entrées de contenu) et les Bloks (composants réutilisables comme des sections hero, des grilles de fonctionnalités ou des CTA). Les développeurs définissent les schémas des Bloks dans le tableau de bord Storyblok, et les éditeurs composent les pages en glissant-déposant des Bloks dans les Stories.

Pensez-y comme des LEGO. Les Stories sont les bases — les pages que vous construisez. Les Bloks sont les briques individuelles — une section hero, une carte de témoignage, un tableau de tarification. Vous définissez quels champs chaque type de Blok possède (titre, image, texte CTA), et les éditeurs les assemblent.

Les Stories : vos entrées de contenu

Chaque page, article ou entrée de contenu dans Storyblok est une Story. Les Stories vivent dans une structure de dossiers (comme un système de fichiers), et chaque Story possède un slug qui correspond à une URL. Le corps d'une Story est composé de Bloks — c'est essentiellement un conteneur.

Les Stories peuvent aussi contenir du contenu non-page. Vous pourriez avoir une Story appelée "site-settings" qui stocke vos liens de navigation, le texte du footer et vos URLs de réseaux sociaux. La flexibilité est similaire à la façon dont vous utiliseriez des documents singleton dans Sanity.

Les Bloks : les briques réutilisables

Les Bloks se déclinent en deux types : nestable (imbriquable) et content type (type racine). Les Bloks de type content type définissent le schéma de haut niveau d'une Story (comme "Page" ou "BlogPost"). Les Bloks nestables sont les composants que les éditeurs glissent dans le corps d'une Story — sections hero, galeries d'images, accordéons FAQ.

Chaque Blok possède un schéma qui définit ses champs. Vous les créez dans le tableau de bord Storyblok sous "Components" (pas dans le code, ce qui est une différence clé par rapport à l'approche schéma-en-code de Sanity).

La modélisation de contenu en pratique

Voici à quoi ressemble le schéma d'un Blok Hero défini via la Management API :

{
  "component": {
    "name": "hero",
    "display_name": "Hero Section",
    "schema": {
      "headline": { "type": "text", "required": true, "pos": 0 },
      "subheadline": { "type": "textarea", "pos": 1 },
      "background_image": { "type": "asset", "filetypes": ["images"], "pos": 2 },
      "cta_text": { "type": "text", "pos": 3 },
      "cta_link": { "type": "multilink", "pos": 4 }
    },
    "is_root": false,
    "is_nestable": true
  }
}

Et le composant React qui affiche ce Blok :

// components/bloks/Hero.jsx
import { storyblokEditable } from "@storyblok/react/rsc";

export default function Hero({ blok }) {
  return (
    <section {...storyblokEditable(blok)} className="hero">
      <div className="hero-content">
        <h1>{blok.headline}</h1>
        {blok.subheadline && <p>{blok.subheadline}</p>}
        {blok.cta_text && (
          <a href={blok.cta_link?.cached_url} className="cta-button">
            {blok.cta_text}
          </a>
        )}
      </div>
      {blok.background_image?.filename && (
        <img
          src={blok.background_image.filename}
          alt={blok.background_image.alt || ""}
        />
      )}
    </section>
  );
}

L'appel storyblokEditable(blok) est ce qui active le clic-pour-éditer dans l'éditeur visuel. Sans lui, le composant s'affiche correctement, mais les éditeurs ne peuvent pas cliquer dessus pour modifier les champs. Facile à oublier, pénible à déboguer.

Les API Storyblok : REST vs GraphQL vs Management

Storyblok propose trois API : la Content Delivery API (REST, recommandée pour la plupart des projets), une API GraphQL (en lecture seule, utile pour les requêtes sélectives), et la Management API (pour les opérations programmatiques sur le contenu comme les migrations et les mises à jour en masse). Storyblok recommande REST pour les nouveaux projets.

La plupart des guides sur les CMS headless ignorent entièrement la couche API. C'est une erreur — l'API que vous choisissez affecte vos temps de build, votre stratégie de mise en cache et votre marge sur les limites de débit.

Content Delivery API (REST)

C'est l'API principale, celle que vous utiliserez 90 % du temps. Elle prend en charge le filtrage, le tri, la pagination et la résolution des relations entre Stories. Les limites de débit sont généreuses : 50 requêtes/seconde sur les plans payants.

// Récupération d'une story via la Content Delivery API
const response = await fetch(
  `https://api.storyblok.com/v2/cdn/stories/home?version=draft&token=${process.env.STORYBLOK_TOKEN}`
);
const { story } = await response.json();
console.log(story.content); // Vos données Bloks

API GraphQL

L'API GraphQL est en lecture seule et a des limites de débit différentes (100 points de complexité par seconde). Elle est utile quand vous voulez un typage fort et n'avez pas besoin du payload Story complet — vous pouvez demander exactement les champs dont vous avez besoin.

{
  PageItem(id: "home") {
    name
    slug
    content {
      _uid
      component
      headline
      subheadline
    }
  }
}

Management API

La Management API gère les opérations CRUD sur votre espace Storyblok : créer des Stories, mettre à jour les schémas de composants, gérer les assets et exécuter des migrations. Vous l'utiliserez pour les pipelines CI/CD, les mises à jour de contenu en masse, ou pour construire des outils personnalisés autour de Storyblok.

Quelle API choisir ?

Pour la plupart des projets Next.js, Nuxt ou Astro, l'API REST Content Delivery avec storyblok-js-client ou le SDK officiel couvre tout ce dont vous avez besoin. Passez à GraphQL si votre modèle de contenu est complexe et que vous récupérez des structures profondément imbriquées avec de nombreux champs inutiles.

Tarifs Storyblok en 2026

La tarification de Storyblok commence par un plan Starter gratuit. Les plans payants débutent à 99 $/mois pour le plan Growth (5 utilisateurs). Les niveaux supérieurs incluent Growth Plus, Premium (mid-market) et Elite (illimité). Une nouvelle grille tarifaire est entrée en vigueur le 7 avril 2026, avec une période de grâce de 60 jours pour les abonnés mensuels existants.

Voici le détail des niveaux de tarification actuels :

Storyblok propose également un essai gratuit de 45 jours du plan Growth Plus, ce qui est inhabituellement généreux comparé aux 30 jours d'essai de Contentful ou au niveau gratuit basé sur l'utilisation de Sanity.

L'analyse honnête sur les tarifs : Storyblok peut devenir coûteux à grande échelle. Les discussions sur Reddit entre agences mentionnent régulièrement l'escalade des prix au fil de la croissance des projets — plus d'utilisateurs, plus d'appels API, plus d'espaces pour les configurations multi-sites. Si vous avez des contraintes budgétaires, l'option self-hosted gratuite de Strapi ou le modèle open source de Payload vous offrent plus de flexibilité, au prix de la gestion de votre propre infrastructure.

Pour les projets personnels et les prototypes, le plan Starter gratuit fait l'affaire. Pour les projets en production avec 2 à 5 éditeurs de contenu, le plan Growth à 99 $/mois est compétitif. Au-delà, demandez un devis personnalisé à l'équipe commerciale de Storyblok — les tarifs publiés ne racontent qu'une partie de l'histoire.

Les nouveautés 2026 : FlowMotion, Blueprints et IA

En 2026, Storyblok a lancé FlowMotion (31 mars), une couche d'automatisation des workflows construite sur n8n avec plus de 500 intégrations. Les Blueprints, lancés en juillet 2025, fournissent une configuration guidée de projets avec des starters spécifiques à chaque framework. Les fonctionnalités IA incluent AI Translate (34+ langues), la Salle d'idéation pour le brainstorming de contenu, et des outils d'IA pour le SEO.

Aucun autre guide sur Storyblok ne couvre encore ces fonctionnalités. Voici ce qui est réellement disponible.

FlowMotion : l'automatisation des workflows

FlowMotion est la réponse de Storyblok au goulot d'étranglement des opérations de contenu. Selon leur annonce de lancement, 75 % des marketeurs consacrent plus de 6 heures par semaine à des tâches de coordination du contenu — notifier les parties prenantes, déclencher des traductions, planifier des publications sur les réseaux sociaux.

FlowMotion est construit sur n8n managé (l'outil d'automatisation de workflows open source) et se connecte à plus de 500 intégrations. Vous définissez des déclencheurs sur des événements de contenu — création, mise à jour, approbation, traduction, planification, publication — et FlowMotion exécute le workflow automatiquement. Imaginez : un éditeur publie un article de blog, et FlowMotion déclenche automatiquement la traduction par IA en 10 langues, notifie l'équipe réseaux sociaux via Slack, et planifie une publication Twitter/X.

C'est un module complémentaire Enterprise/Elite, donc les petites équipes n'y auront pas accès. Mais pour les organisations gérant du contenu sur plusieurs marchés et canaux, c'est un gain de temps considérable.

Blueprints : la configuration guidée de projets

Les Blueprints résolvent un vrai point de friction : la configuration initiale d'un projet Storyblok. Une étude de 2024 a révélé que 24 % des développeurs seniors estiment que la configuration initiale d'un projet CMS prend des jours, pas des heures.

Storyblok propose deux niveaux de Blueprints :

• Core Blueprint : Configuration minimale — connecte votre framework (Next.js, Nuxt ou Astro), crée un espace et déploie un starter de base. Idéal pour les développeurs qui veulent une ardoise vierge.
• Business Blueprint : Configuration prête pour la production avec des composants préconstruits, un modèle de contenu configuré et un déploiement vers Vercel ou Netlify. Plus proche d'une expérience "lancer en 30 minutes".

Vous choisissez votre framework, optez pour Core ou Business, et Storyblok crée un dépôt GitHub connecté avec un pipeline de déploiement. Cela fait gagner des heures de configuration de boilerplate par rapport à un démarrage de zéro.

Fonctionnalités IA : Translate, Salle d'idéation et plus encore

Les fonctionnalités IA de Storyblok adoptent une approche "apportez votre propre fournisseur". Vous connectez votre clé API OpenAI ou Google Gemini, et Storyblok l'utilise pour :

• AI Translate : Traduire le contenu en 34+ langues directement dans l'éditeur. Ce n'est pas un remplacement pour la traduction professionnelle sur du contenu critique, mais c'est excellent pour les brouillons et le contenu interne.
• Salle d'idéation : Brainstorming collaboratif par IA pour les idées de contenu. Les éditeurs décrivent ce dont ils ont besoin, et l'IA génère des plans, des titres et des brouillons.
• Alt Text IA : Génération automatique de texte alternatif pour les images.
• SEO IA : Suggestions de balises méta title et meta description basées sur votre contenu.

Le modèle "apportez votre propre clé" signifie que vous maîtrisez vos coûts et évitez la dépendance fournisseur sur la tarification IA. Storyblok a également une fonctionnalité "Concept Room" en développement, qui vise à combiner l'idéation avec la planification visuelle du contenu.

L'internationalisation avec Storyblok

Storyblok gère l'i18n par traduction au niveau des champs, ce qui signifie que vous avez une seule Story avec des variantes traduites pour chaque langue plutôt que de dupliquer l'ensemble du document par langue. C'est fondamentalement différent de Contentful et Sanity, qui utilisent la traduction au niveau du document — et ça compte à grande échelle.

Pourquoi la traduction au niveau des champs l'emporte-t-elle ? Imaginez un site marketing en 10 langues. Avec l'i18n au niveau document (Contentful, Sanity), vous auriez 10 documents distincts pour chaque page. Vous modifiez la mise en page ? Vous mettez à jour 10 documents. Avec l'approche de Storyblok au niveau des champs, vous avez une seule Story. La structure reste identique — seuls les champs texte ont des variantes par langue. Modifiez la mise en page une fois, et les 10 langues se mettent à jour.

AI Translate accélère encore le processus. Les éditeurs rédigent le contenu dans leur langue principale, cliquent sur "Translate", et l'IA remplit les autres langues via leur fournisseur OpenAI ou Gemini connecté. 34+ langues sont prises en charge.

Voici comment récupérer du contenu traduit :

// Récupération d'une story en allemand
const response = await fetch(
  `https://api.storyblok.com/v2/cdn/stories/home` +
  `?version=published` +
  `&language=de` +
  `&token=${process.env.STORYBLOK_TOKEN}`
);
const { story } = await response.json();
// story.content contient maintenant les traductions en allemand
// Les champs non traduits reviennent automatiquement à la langue par défaut

Le paramètre language fait tout le travail. Les champs non traduits reviennent automatiquement à la langue par défaut, donc vous n'aurez jamais une page cassée à cause de traductions incomplètes.

Storyblok face aux alternatives

Après avoir testé ces cinq CMS pour nos propres projets, voici comment ils se comparent sur les fonctionnalités qui comptent vraiment pour les décisions de projet :

Choisissez Storyblok si votre projet implique à la fois des développeurs et des éditeurs de contenu non techniques qui ont besoin de voir les modifications visuellement. L'éditeur visuel est inégalé, et l'i18n au niveau des champs est la meilleure de sa catégorie pour les sites multilingues.

Choisissez Sanity si votre équipe est très orientée développeurs et que vous voulez un maximum de flexibilité sur les schémas. L'approche schéma-en-code de Sanity et le langage de requête GROQ vous donnent plus de contrôle, mais les éditeurs obtiennent une interface basée sur des formulaires, pas un aperçu visuel. Lisez notre guide Sanity pour le tableau complet.

Choisissez Strapi ou Payload si vous avez besoin du self-hosting ou du contrôle open source. Ni Storyblok, ni Sanity, ni Contentful ne vous permettent d'exécuter le CMS sur vos propres serveurs. Strapi et Payload le font. Consultez notre guide Strapi ou notre guide Payload pour les détails.

Choisissez Contentful si vous êtes dans un environnement enterprise qui valorise la maturité de l'écosystème, les nombreuses intégrations du marketplace et les outils développeurs établis. Lisez notre guide Contentful.

Pour la comparaison complète avec notation et recommandations pour des projets réels, consultez notre comparatif CMS headless complet.

Quand ne pas utiliser Storyblok

Tout CMS a des points bloquants pour certains projets. Voici ceux de Storyblok :

Vous avez besoin du self-hosting. Storyblok est SaaS uniquement — pas d'option on-premises, pas d'image Docker, pas de déploiement auto-géré. Si votre organisation exige la souveraineté des données ou l'hébergement on-prem, regardez du côté de Payload pour les projets self-hosted ou de Strapi.

Vous voulez un schéma-en-code. Les schémas de composants Storyblok sont définis dans l'interface du tableau de bord, pas dans votre codebase. Vous pouvez les exporter et les importer via la Management API, mais ils ne vivent pas dans votre dépôt Git comme source de vérité. Si les schémas versionnés comptent pour votre équipe, Sanity et Payload proposent tous deux une modélisation de contenu code-first.

Vous avez des contraintes budgétaires à grande échelle. La tarification de Storyblok fonctionne bien pour les petites et moyennes équipes. Mais si vous gérez plus de 15 espaces sur plusieurs marques avec des dizaines d'éditeurs, les coûts s'accumulent. Strapi ou Payload en self-hosted éliminent entièrement les frais de licence CMS.

Votre équipe est composée uniquement de développeurs. L'éditeur visuel est la fonctionnalité premium de Storyblok. Si personne dans votre équipe n'a besoin d'un aperçu visuel — si tout le monde est à l'aise pour éditer du JSON ou utiliser une interface basée sur des formulaires — vous payez pour une fonctionnalité que vous n'utiliserez pas.

Vous avez besoin d'un accès direct à la base de données. Storyblok abstrait entièrement sa couche de stockage. Pas de connexion Postgres, pas de requêtes SQL, pas d'accès direct aux données. Si votre projet nécessite des requêtes de base de données personnalisées ou des jointures avec d'autres sources de données au niveau base de données, Payload (construit sur MongoDB/Postgres) vous offre ça.

D'après notre expérience à construire sur plusieurs CMS, Storyblok brille quand les développeurs et les éditeurs de contenu collaborent sur le même projet. Si votre équipe est composée uniquement de développeurs, la prime pour l'éditeur visuel ne vaut pas la peine d'être payée.

Démarrer avec Storyblok

Le chemin le plus rapide de zéro à un projet Storyblok fonctionnel prend environ 30 minutes avec les Blueprints, ou une heure sans. Voici la séquence :

Étape 1 : Créez un compte. Inscrivez-vous gratuitement sur storyblok.com. Le plan Starter vous donne un espace avec 25 000 appels API/mois — suffisant pour le développement et le prototypage.

Étape 2 : Choisissez un Blueprint ou démarrez de zéro. Si vous voulez un projet préconfiguré, choisissez un Blueprint (Core pour minimal, Business pour prêt à la production). Si vous préférez construire de zéro, créez un espace vide.

Étape 3 : Connectez votre frontend. Storyblok a des SDK officiels et des starters pour Next.js, Nuxt, Astro, SvelteKit, Remix, Angular et Gatsby. Pour un projet Next.js App Router :

npx create-next-app@latest my-storyblok-site
cd my-storyblok-site
npm install @storyblok/react

Étape 4 : Configurez l'URL de prévisualisation de l'éditeur visuel. Dans les paramètres de votre espace Storyblok, définissez l'URL de prévisualisation vers votre serveur de développement local (ex. https://localhost:3000/). L'éditeur visuel nécessite HTTPS — utilisez next dev --experimental-https ou un outil comme mkcert.

Étape 5 : Définissez votre premier Blok et créez une Story. Rendez-vous dans "Components" dans le tableau de bord Storyblok, créez un type de contenu "Page" avec un champ body, puis créez un Blok "Hero" nestable. Créez votre première Story en utilisant le type de contenu "Page". Glissez-y le Blok Hero. Voyez-le se restituer dans l'éditeur visuel.

Pour des guides de démarrage rapide spécifiques à chaque framework, Storyblok maintient une page des technologies avec des tutoriels de configuration pour chaque framework pris en charge. Si vous décidez entre des frameworks pour votre frontend, notre comparatif Next.js vs Remix couvre les compromis, et notre guide Vercel vs Netlify aide pour les décisions de plateforme de déploiement.

FAQ

Qu'est-ce que Storyblok CMS ?

Storyblok est un système de gestion de contenu headless avec un éditeur visuel intégré, fondé en 2017 à Linz, en Autriche. Il utilise une architecture basée sur des composants appelée Bloks pour la modélisation du contenu et délivre le contenu via des API REST et GraphQL. Storyblok est utilisé par des entreprises comme Adidas, Tesla et Oatly pour des sites web, des applications et la diffusion de contenu multicanal.

Storyblok est-il gratuit ?

Oui, Storyblok propose un plan Starter gratuit avec un utilisateur, un espace et 25 000 appels API par mois. Les plans payants débutent à 99 $/mois pour le niveau Growth avec cinq utilisateurs. Storyblok propose également un essai gratuit de 45 jours du plan Growth Plus, ce qui est plus généreux que les périodes d'essai de la plupart des concurrents.

Comment fonctionne l'éditeur visuel de Storyblok ?

L'éditeur visuel de Storyblok charge votre application frontend dans une iframe et superpose des zones éditables sur chaque composant (Blok). Les éditeurs cliquent directement sur les éléments de la page pour les modifier et voient les changements en temps réel. La bibliothèque JavaScript StoryblokBridge est nécessaire dans votre code frontend pour connecter l'iframe à l'interface d'édition de Storyblok.

Storyblok est-il meilleur que Contentful ?

Ça dépend de vos priorités. Storyblok offre un éditeur visuel supérieur et une internationalisation au niveau des champs, ce qui le rend plus adapté aux équipes marketing gérant du contenu multilingue. Contentful dispose d'un écosystème plus mature, d'un marketplace d'intégrations plus fourni et d'une adoption enterprise plus établie. Les deux sont SaaS uniquement avec des structures tarifaires similaires.

Quels frameworks Storyblok prend-il en charge ?

Storyblok fournit des SDK officiels et des templates de démarrage pour Next.js, Nuxt, Astro, SvelteKit, Remix, Angular et Gatsby. Le SDK React (@storyblok/react) et le SDK Vue (@storyblok/vue) couvrent les deux écosystèmes les plus populaires. Les Blueprints prennent actuellement en charge Next.js, Nuxt et Astro pour la configuration guidée de projets.

Peut-on héberger Storyblok soi-même ?

Non. Storyblok est une plateforme SaaS uniquement, sans option de self-hosting ou d'on-premises. Si le self-hosting est une exigence pour votre projet — pour des raisons de souveraineté des données, de conformité ou de coût — envisagez Strapi (open source, basé sur Node.js) ou Payload CMS (open source, natif Next.js) comme alternatives qui prennent en charge les déploiements entièrement auto-hébergés.

Qu'est-ce que FlowMotion dans Storyblok ?

FlowMotion est la fonctionnalité d'automatisation des workflows de Storyblok, lancée le 31 mars 2026. Construite sur n8n managé, elle se connecte à plus de 500 intégrations et automatise les opérations de contenu comme les déclencheurs de traduction, les notifications aux parties prenantes et la publication multiplateforme. FlowMotion est disponible en tant que module complémentaire Enterprise/Elite, non inclus dans les plans Growth ou Growth Plus.

Comment Storyblok gère-t-il l'internationalisation ?

Storyblok utilise la traduction au niveau des champs, ce qui signifie qu'une Story contient des variantes traduites de chaque champ plutôt que de dupliquer l'ensemble du document par langue. Cette approche s'adapte mieux que l'i18n au niveau document (utilisé par Contentful et Sanity) pour les sites avec de nombreuses langues. AI Translate prend en charge 34+ langues via votre propre clé API OpenAI ou Gemini.

Qui utilise Storyblok ?

La liste de clients de Storyblok inclut Adidas, Tesla, Oatly, Virgin Media O2, dm-drogerie markt, Spendesk et Panini. La plateforme sert à la fois de grandes organisations gérant des opérations de contenu multi-marchés et des startups en croissance qui ont besoin d'un éditeur visuel pour autonomiser leurs équipes éditoriales non techniques. Storyblok a levé 138 M$ en financement total via sa Série C.

Que sont les Blueprints Storyblok ?

Les Blueprints sont des templates de configuration guidée de projets lancés en juillet 2025 par Storyblok. Choisissez un Core Blueprint (starter minimal) ou un Business Blueprint (prêt pour la production avec des composants préconstruits). Sélectionnez votre framework — Next.js, Nuxt ou Astro — et Storyblok crée un dépôt GitHub connecté avec un pipeline de déploiement vers Vercel ou Netlify en quelques minutes.