« C’est juste un blog, on le fait en un sprint » : tôt ou tard, cette phrase est prononcée dans le canal technique de chaque SaaS, et elle est même à peu près vraie. Une table d’articles, deux ou trois routes, un champ Markdown : un sprint. Ce que l’estimation oublie, c’est tout ce qui manque à la version sprint, et tout ce que coûtent les années qui suivent. J’ai construit cette infrastructure (Kookee existe parce que je pense que la plupart des équipes ne devraient pas avoir à le faire), alors voici les comptes, sans rien cacher.
Ce que devient vraiment « juste un blog »
La version sprint n’a pas d’éditeur digne de ce nom, alors la liste s’allonge tout de suite :
L’éditeur. Le marketing n’écrira pas dans des fichiers Markdown derrière une pull request. Un vrai éditeur de texte riche (images, contenus intégrés, blocs de code, une annulation qui marche) demande des semaines de travail, même en s’appuyant sur un framework d’éditeur open source, et il réclame de l’attention pour toujours.
La gestion des médias. Téléversements, stockage, redimensionnement des images, un chemin via CDN, des limites de taille. Chaque système de contenu finit par en avoir une ; le vôtre aussi.
Le workflow. Brouillons, publication programmée, liens de prévisualisation, et un historique des révisions que quelqu’un réclamera la première fois qu’un rédacteur écrasera une heure de travail.
Les champs autour du contenu. Les slugs et leur unicité, les tags, les catégories, les métadonnées SEO, les images Open Graph, les horodatages.
Puis arrive le deuxième module. Un journal des modifications réclame des types et des versions ; un centre d’aide, des catégories et une recherche ; les retours, des votes, des statuts et des commentaires. Chacun est « petit », chacun réimplémente la rédaction, le stockage et la diffusion à sa manière, et chacun devient un produit interne de plus, dont vous êtes le seul mainteneur.
Une estimation prudente pour un blog, un journal des modifications et un centre d’aide avec une interface d’administration utilisable se compte en mois d’ingénierie, pas en sprints. Au coût complet habituel d’un ingénieur, c’est déjà une vraie somme avant qu’un seul utilisateur voie une page, et c’est la partie bon marché.
La ligne budgétaire que tout le monde oublie : pour toujours
L’estimation s’arrête au lancement. Le système, non :
Sécurité et dépendances. Votre système de contenu est désormais une surface d’attaque (authentification, téléversements, une API publique) que vous corrigez à votre rythme, pour toujours. Mises à jour de dépendances, migrations de framework, la version majeure cassante de la bibliothèque d’éditeur : autant de taxes annuelles.
Infrastructure. Hébergement, base de données, stockage objet, CDN, supervision, sauvegardes. Chaque poste est petit ; ensemble, ils font une facture permanente et une astreinte permanente.
La course sans fin aux fonctionnalités. Une recherche qui trouve vraiment (aujourd’hui, cela veut dire recherche sémantique et embeddings), des traductions quand vous partez à l’international, des réponses IA quand les centres d’aide de vos concurrents en ont. Chacune est un projet sur un système dont personne ne veut s’occuper.
La maintenance d’une infrastructure de contenu interne se chiffre vraisemblablement en semaines d’ingénierie par an, discrètement, éparpillées en « correctifs rapides » qui ne le sont jamais. Le coût le plus lourd est un coût d’opportunité : chaque heure passée là n’est pas passée sur le produit pour lequel vos clients paient. L’infrastructure de contenu est un produit de base, que tout le monde vend ; votre produit, non. La vraie erreur, c’est de dépenser un temps d’ingénierie rare sur ce produit de base, quelle que soit la facture.
Les raisons de développer quand même
Un article « développer ou acheter » qui ne concède jamais rien au développement est une publicité. Il existe de vraies raisons de développer :
Le contenu est votre produit. Si vous êtes une plateforme de publication, une entreprise de documentation, ou si vos workflows de contenu sont ce qui vous distingue : développez. L’outil générique vous mettra des bâtons dans les roues.
Des contraintes strictes. Des environnements réglementés où le contenu doit rester dans votre infrastructure, des déploiements isolés du réseau, des règles de résidence des données qu’un fournisseur ne peut pas respecter.
Des modèles vraiment inhabituels. Votre contenu ne ressemble vraiment pas à des entrées avec des champs. Vérifiez quand même si les types d’entrées personnalisés d’une plateforme le couvrent avant de conclure que non.
Ce qui ne tient pas : « on développera exactement ce dont on a besoin, rien de plus ». La liste de besoins ci-dessus n’est pas une surenchère de fonctionnalités de fournisseur : c’est ce vers quoi converge tout système de contenu, parce que rédacteurs, marketeurs et lecteurs demandent toujours les mêmes choses.
Ce que l’achat doit vraiment vous apporter
Si vous achetez, exigez du fournisseur le niveau qui justifie de ne pas développer :
Votre domaine et votre frontend. Du contenu livré en JSON par une API et un SDK, rendu par votre application avec votre design system : le SEO profite à votre domaine, et rien n’a l’air rapporté. Si le fournisseur tient à héberger vos pages, vous avez acheté un constructeur de sites, pas une infrastructure.
Pas d’enfermement. Tout est récupérable en JSON documenté avec votre clé API. C’est justement parce que la porte de sortie est ouverte qu’on peut entrer sans risque.
Tous les modules, un seul système. Blog, journal des modifications, centre d’aide, retours, pages : la valeur s’additionne quand le tableau de retours renvoie à l’entrée du journal des modifications et que le centre d’aide alimente les réponses IA, avec une seule interface d’administration et une seule API au lieu de quatre fournisseurs assemblés, dont les abonnements cumulés dépassent souvent, de toute façon, celui d’une plateforme unique.
Un démarrage gratuit. Vous devez pouvoir valider l’intégration avant de payer quoi que ce soit.
C’est sur ce modèle que Kookee est construit : un backend de contenu avec les modules dont les produits SaaS ont réellement besoin, un SDK typé et des hooks React pour la couche de rendu, un portail hébergé pour le premier jour, et une livraison API-first, pour que le seul code qui vous appartienne soit la fine couche qui a toujours été la vôtre : le rendu.
Une méthode de décision
Le contenu est-il ce qui vous distingue, ou une contrainte stricte est-elle en jeu ? Si oui, développez, délibérément et avec une équipe dédiée.
Sinon, prototypez la voie de l’achat : affichez votre liste d’articles et un article d’aide via le SDK d’une plateforme, sur votre domaine. Prévoyez une journée.
Chiffrez honnêtement le développement : les premiers mois plus la maintenance annuelle, au coût complet, face à l’abonnement.
Décidez une fois, par écrit, et arrêtez de rouvrir le débat chaque fois que quelqu’un dit « c’est juste un blog ».
Le blog à la taille d’un sprint existe bel et bien : vous pouvez l’avoir d’ici vendredi. Le prix de l’achat se compare aux cinq années qui suivent ce vendredi.