Chaque produit que j’ai lancé est passé par la même semaine.
L’application principale fonctionne. Quelqu’un demande où est le journal des modifications. Quelqu’un d’autre veut un centre d’aide. Le marketing a besoin d’un blog avec tags et recherche. Le service juridique veut une page de CGU modifiable sans déploiement. Les commerciaux veulent une feuille de route publique. Et chacun de ces éléments, c’est une table en base de données, un éditeur, une route publique et un pipeline de déploiement qui n’ont rien à voir avec le produit que vous construisez vraiment.
Alors vous faites comme tout le monde. Vous greffez un CMS headless pensé pour des magazines, ou vous branchez trois outils SaaS qui s’ignorent, ou, le plus souvent, vous écrivez une énième table posts en vous promettant de la rendre propre plus tard.
Les sept briques
Regardez n’importe quel produit SaaS arrivé à maturité, et vous trouverez à peu près les mêmes briques de contenu :
Un blog, avec tags, recherche et pagination
Un journal des modifications, avec versions et types de changement
Un centre d’aide, avec catégories et recherche
Des pages statiques — CGU, Confidentialité, À propos
Des annonces affichées dans l’application
De la configuration à distance et des feature flags
Des retours et une feuille de route publique
Aucune n’est difficile. Toutes ensemble, elles prennent un quart du temps d’ingénierie, un temps qui n’apparaît jamais sur une feuille de route, parce que chacune arrive séparément et que chacune a l’air petite.
Ce qu’est Kookee
Kookee est un backend de contenu pour les développeurs. Un projet, une clé API, et les sept briques :
import { Kookee } from '@kookee/sdk';
const kookee = new Kookee({ apiKey: process.env.KOOKEE_API_KEY! });
const posts = await kookee.blog.list({ limit: 10 });
const releases = await kookee.changelog.list({ filter: { changelogType: 'feature' } });
const articles = await kookee.help.search({ query: 'billing' });
const flag = await kookee.config.getByKey('feature-new-checkout');Votre équipe écrit dans un vrai éditeur, dans le tableau de bord. Votre application lit le contenu via un SDK typé. Entre les deux, rien ne demande de déploiement.
Les trois décisions qui l’ont façonné
Le contenu, ce sont des données, pas des pages. Kookee ne fait jamais le rendu de votre frontend. Il renvoie du JSON avec un corps en HTML, et c’est vous qui décidez de son apparence. C’est la différence entre un CMS qui s’approprie votre design et un backend qui reste à sa place. Le portail hébergé et les composants React facultatifs sont là pour les équipes qui en veulent ; l’API, elle, reste headless.
TypeScript d’abord, pas TypeScript plus tard. Le SDK n’a aucune dépendance et repose sur le fetch natif. Chaque module, chaque paramètre et chaque forme de réponse est typé : un nom de méthode ou de paramètre erroné devient une erreur de compilation, pas une surprise en production.
Une seule clé, publiable sans risque. La clé API ne lit que le contenu déjà publié, plus des actions sans danger pour un visiteur anonyme, comme les réactions. Elle a donc sa place dans un bundle navigateur : pas de signature à orchestrer, pas de route proxy à construire avant que votre première page fonctionne. L’écriture se fait dans le tableau de bord, ou via un assistant IA connecté avec votre propre jeton MCP, qui reste sur votre machine.
Ce que Kookee n’est pas
Kookee n’est pas un constructeur de pages, et il ne cherche pas à devenir la base de données de votre application. Si votre contenu est généré par les utilisateurs à grande échelle, ou s’il est le produit lui-même, il vous faut vos propres tables. Kookee sert au contenu autour du produit : ce que votre équipe écrit et que vos utilisateurs ont besoin de lire.
Par où commencer
Installez le SDK et laissez un assistant de code brancher la première brique. Les types sont livrés avec le paquet, donc l’assistant s’appuie sur les vraies signatures des méthodes au lieu de les deviner :
npm install @kookee/sdkCréez un blog avec le paquet
@kookee/sdk, déjà installé. Une page de liste avec filtre par tags et pagination, et une page de détail avec le contenu HTML rendu.
Quinze minutes plus tard, vous avez une page de blog qui fonctionne et une tâche de moins dans le backlog. Ensuite, le journal des modifications. Puis le centre d’aide. C’est toute l’idée.