Présentation du projet

Le Labo du Yeti est un CMS HTML headless propulsé par l'IA, conçu pour permettre aux agences web et aux freelances de livrer rapidement des sites statiques sur mesure, tout en confiant ensuite la gestion éditoriale à leurs clients via une interface d'administration claire, sécurisée et étendue par un système d'extensions.

Vision & raison d'être

Le Labo du Yeti part d'un constat très concret du quotidien des intégrateurs : les CMS du marché imposent presque toujours un compromis frustrant. Soit le développeur garde une totale liberté de code (Strapi, Sanity, Directus) mais doit reconstruire à chaque projet la couche éditoriale et le pipeline de publication statique. Soit l'éditeur dispose d'un confort d'utilisation (WordPress, Webflow) mais le développeur perd la maîtrise du HTML et hérite d'un thème, d'un constructeur visuel ou d'un format propriétaire imposé.

Le Labo du Yeti tranche ce dilemme avec un parti pris radical : le HTML reste la source de vérité. Le développeur écrit (ou fait générer par IA) des fragments HTML standards, balisés avec deux familles d'attributs data-cms et data-ai qui pilotent l'édition côté client et la génération côté serveur. Le CMS ne réinterprète pas la structure : il l'injecte telle quelle dans un layout global, applique les overrides définis dans le builder visuel, puis publie un site statique rapide, propre et facilement hébergeable sur n'importe quel mutualisé Plesk.

Public cible

L'outil s'adresse aux profils qui veulent garder la main sur le code tout en industrialisant la livraison de sites éditables :

• Agences web qui livrent plusieurs sites par mois et cherchent un socle unifié plutôt que de jongler entre WordPress, Webflow et Framer selon les clients.
• Freelances intégrateurs / développeurs front qui veulent offrir à leurs clients une interface d'édition simple sans renoncer à un HTML/CSS maîtrisé.
• Studios SEO qui exploitent intensivement le cocon sémantique et la génération de pages locales (service × ville).
• Équipes produit internes qui ont besoin d'un site corporate ou marketing rapide à mettre à jour sans dépendance à un thème WordPress.

Les clients finaux (chefs d'entreprise, responsables communication, rédacteurs) sont traités comme des utilisateurs de premier rang via le rôle editor, qui leur ouvre l'accès aux pages, articles de blog, médias et formulaires, mais filtre les sections sensibles (SMTP, branding sidebar, clés IA, sécurité).

Positionnement vs alternatives

Pour situer Le Labo du Yeti dans l'écosystème CMS, voici une matrice de comparaison sur les axes qui guident le choix d'un outil au quotidien :

Le Labo du Yeti ne cherche pas à remplacer WordPress sur tous les usages : un site très communautaire, une boutique WooCommerce ou un forum BuddyPress restent mieux servis par leur écosystème historique. En revanche, sur le créneau du site vitrine éditable, du site corporate, du landing pack et du cocon SEO local, l'outil propose un compromis rare entre maîtrise du code, confort éditorial et productivité IA.

Philosophie & principes directeurs

Trois conventions structurent l'ensemble de la base de code et conditionnent toutes les fonctionnalités à venir. Les comprendre permet de saisir pourquoi le CMS reste léger malgré son périmètre fonctionnel.

Deux familles d'attributs : data-cms et data-ai

Les fragments HTML utilisés comme templates de page, d'article ou de cocon sont enrichis de deux types de marqueurs. Les attributs data-cms-* indiquent au builder visuel quelles zones sont éditables par un humain (texte, image, lien, formulaire, bloc répétable). Les attributs data-ai-* signalent au pipeline de génération quelles zones doivent être remplies par l'IA (titre h1, intro, paragraphes, FAQ, CTA, stats, tables, JSON-LD).

Cette séparation explicite permet à un même template d'être à la fois injecté en masse par l'IA (cocon de 200 pages locales par exemple) et retouché finement par un client via le builder visuel, sans qu'aucun code spécifique au CMS ne fuite dans le HTML final.

Builder iframe avec postMessage

Plutôt que d'imposer un format propriétaire (blocs Gutenberg, widgets Elementor, composants React), le builder visuel travaille directement sur le HTML rendu, chargé dans une iframe sandboxée. La sélection au clic, les changements de balise (h1↔h6, p↔span), les styles sûrs (couleur, alignement, gras / italique, fond de bouton) et le WYSIWYG inline communiquent avec le panneau d'édition React via postMessage.

Les modifications sont stockées sous forme d'overrides dans page.overrides[key], ce qui garantit que le template HTML d'origine reste intact et qu'une mise à jour du template par l'agence ne casse pas les retouches du client. C'est aussi cette architecture qui rend le builder utilisable indifféremment sur les pages, les articles de blog et les pages générées par cocon.

Système d'extensions à la WordPress

Le coeur du CMS reste volontairement compact. Tout ce qui peut être déporté (intégration tierce, connecteur de feedback, conversion d'images, intégration Slack, etc.) passe par le système d'extensions. Une extension est un dossier extensions/installed/<id>/ contenant un manifest.json qui déclare ses permissions, ses hooks, sa configuration et, optionnellement, une entrée de sidebar et une page custom.

Le contexte injecté expose 45 helpers (ext.router, ext.hooks, ext.storage, ext.settings, ext.logger, ext.cms.*) et 24 permissions distinctes. Les champs sensibles (emails, hashs de mots de passe, clés IA, JWT secret) ne sont jamais exposés, quelle que soit la permission demandée.

Architecture macroscopique

Vue de très haut, l'application se compose d'un backend Node 22 / Express, d'une base SQLite locale avec WAL, d'un frontend React 18 (admin SPA), d'un site public statique publié dans public/, et d'un anneau de services IA externes. Le schéma textuel ci-dessous résume les flux principaux :

                    ┌────────────────────────────────────────────────┐
                    │                  NAVIGATEUR                    │
                    │                                                │
                    │   Admin SPA (React + Vite + Tailwind)          │
                    │   ────────────────────────────────────         │
                    │   • Pages / Blog / Cocon / Médias              │
                    │   • Builder visuel (iframe + postMessage)      │
                    │   • Settings / Extensions / Logs               │
                    │                                                │
                    │   Site public (HTML statique servi par Plesk)  │
                    │   ────────────────────────────────────         │
                    │   • Pages classiques + articles + cocon        │
                    │   • Formulaires data-cms-form (runtime.js)     │
                    └───────────────┬────────────────────────────────┘
                                    │  HTTPS (JWT ou cmstok_*)
                                    ▼
                    ┌────────────────────────────────────────────────┐
                    │           BACKEND  Node 22 + Express           │
                    │                                                │
                    │   Routes /api/* (auth, pages, blog, cocon,     │
                    │   media, forms, layouts, build, ai, images,    │
                    │   extensions, capabilities, backup, logs)      │
                    │                                                │
                    │   Middlewares : requireAuth / requireRole /    │
                    │   requireCapability / rate-limit / helmet      │
                    │                                                │
                    │   Services métier (auth, pages, cocon, blog,   │
                    │   media, forms, ai, images, build, render)     │
                    │                                                │
                    │   Loader extensions + hooks events/filters     │
                    └────┬────────────────┬────────────────────┬─────┘
                         │                │                    │
                         ▼                ▼                    ▼
              ┌────────────────┐ ┌──────────────────┐ ┌──────────────────┐
              │ SQLite (WAL)   │ │ Filesystem       │ │ Services IA      │
              │ content/cms.db │ │ • uploads/       │ │ • Anthropic API  │
              │                │ │ • templates/     │ │ • Unsplash       │
              │ • users        │ │ • brouillons/    │ │ • Pexels         │
              │ • pages        │ │ • public/        │ │ • Pixabay        │
              │ • cocon_groups │ │ • extensions/    │ │ • Brave / SerpAPI│
              │ • articles…    │ │   installed/     │ │ • Tavily         │
              │ • api_tokens   │ │                  │ │ • SMTP (forms +  │
              │ • extensions   │ │                  │ │   notifs cocon)  │
              │ • ai_usage     │ │                  │ │                  │
              │ • logs         │ │                  │ │                  │
              └────────────────┘ └──────────────────┘ └──────────────────┘

Le détail de chaque couche fait l'objet d'une page dédiée : voir Architecture technique, Base de données, API REST et Moteur HTML (pipeline).

Fonctionnalités phares

Le périmètre fonctionnel livré couvre les besoins d'un site vitrine professionnel ou d'un projet SEO local sans dépendance externe. Chaque fonctionnalité est documentée individuellement dans la suite de la documentation technique :

Pages

CRUD complet, bibliothèque de templates HTML prédéfinis et uploadables, preview iframe sécurisé, edition via le builder visuel (3 onglets Contenu / Style / Avancé), styles sûrs et changements de balise dynamiques. Voir Pages (guide utilisateur) et Builder visuel.

Blog IA

Articles avec catégories et tags, génération IA en JSON ou HTML, featured image dynamique (Unsplash / Pexels / Pixabay), cycle de publication draft / scheduled / published, templates HTML globaux uploadables, suggestions de titres via recherche web. Voir Blog IA.

Cocon SEO

Groupes de contenu avec variables cartésiennes (service × ville par exemple), génération IA parallèle, architecture parent/enfant avec slugs composites /parent/enfant, section « Voir plus » filtrée par variable commune. Quota anti-spam configurable (5 pages / 7 jours par défaut) et notifications email aux rôles admin et webmaster 5 minutes après chaque créneau libéré. Voir Cocon SEO.

Builder visuel

Constructeur inspiré d'Elementor, opérant directement sur le HTML rendu via une iframe et postMessage. Sélection au clic, panneau latéral à trois onglets, overrides stockés dans page.overrides[key] pour préserver le template d'origine. Activé sur les pages, les pages parents et enfants du cocon, et bientôt sur le blog.

Extensions

Système de plugins inspiré de WordPress : trois tables dédiées (extensions, extension_settings, extension_data), loader automatique au boot, hooks d'événements (page.*, build.*, cocon.*, etc.) et hooks de filtre chaînables (media.before_save, render.html). Trois extensions sont livrées en exemple : hello-world, webp-auto-converter et surefeedback-connector. Voir Système d'extensions.

Backup & restauration

Export complet du site en ZIP (DB, médias, extensions), restauration avec safety backup automatique avant écrasement, listing des sauvegardes locales, protection anti zip-slip. Endpoint réservé au rôle owner via POST /api/backup/restore. Voir Sécurité.

RBAC granulaire

Quatre rôles canoniques (owner, admin, webmaster, editor) combinés à une matrice de capabilities éditable par l'owner. Chaque feature du CMS (pages, blog, cocon, médias, settings_ai, settings_apis, etc.) peut être activée ou désactivée par rôle. La matrice est consommée à la fois côté backend (requireCapability(featureId)) et côté frontend pour filtrer la sidebar. Voir Authentification & RBAC.

Médiathèque, formulaires, build

Médiathèque centralisée avec grille type WordPress, drawer latéral, filtres par mois et année, conversion WebP automatique via extension. Formulaires détectés automatiquement dans le HTML (<form data-cms-form>), config par formulaire (email, webhook, anti-spam), runtime runtime.js public pour l'embed. Build statique complet (buildSite()) qui compile toutes les pages, articles et pages de cocon dans public/, avec génération de sitemap.xml, robots.txt et page 404 personnalisable. Voir Médiathèque, Formulaires et Build & Publication.

Modèle de déploiement SaaS hybride

Contrairement à un SaaS multi-tenant classique où tous les clients partagent la même base, Le Labo du Yeti adopte un modèle hybride : un client correspond à une instance Node, une base SQLite, un fichier .env et un domaine isolés. Ce choix élimine toute classe de bug liée à l'isolation tenant et reste compatible avec un hébergement mutualisé Plesk classique.

Le revers attendu (multiplication des instances, supervision distribuée) est compensé par les endpoints publics GET /api/health, GET /api/version et GET /api/stats (auth par cmstok_*), pensés pour alimenter une future plateforme de reporting cross-sites. Voir Reporting.

Et la suite ?

Cette page d'introduction balise le terrain. Pour entrer dans le détail technique, la page suivante (Architecture technique) décrit la stack, le découpage en services, le cycle de vie d'une requête et les conventions ESM du backend. La page Structure des dossiers donne ensuite la carte exacte du dépôt, fichier par fichier.

Pour le profil utilisateur final (client, rédacteur), une documentation parallèle existe dans la section Guide utilisateur, qui couvre la prise en main de l'administration sans exposer la mécanique interne.