IWHWI

IWHWI : framework CMS-agnostique piloté par IA via MCP.

Les CMS headless comme Directus exposent des collections et des champs, tandis que Strapi ou Contentful exposent des content types et des champs - mais chacun avec ses propres conventions, son propre SDK et ses propres limites. Résultat : votre modèle de contenu est prisonnier d'un outil, vos automatisations sont à refaire à chaque migration, et l'industrialisation reste artisanale.

IWHWI (Interface Web Headless with Intelligence) est notre framework propriétaire en Clean Architecture qui résout ce problème. Il introduit une couche d'abstraction au-dessus du CMS : les Content Types - composés de Nodes (briques structurelles) et de Fields (champs métier) - sont modélisés dans le domaine métier, indépendamment de l'adaptateur CMS utilisé. Directus, qui ne possède pas nativement le concept de Content Type (contrairement à Strapi ou Contentful), est le premier adaptateur implémenté - le cas le plus complexe. Les autres CMS, qui disposent déjà de ce concept, suivront.

Grâce au protocole MCP (Model Context Protocol), un assistant IA peut créer des structures, synchroniser des données, traduire du contenu et piloter l'ensemble du cycle de vie - le tout depuis une conversation. Découvrez ci-dessous l'architecture, les concepts clés et les capacités concrètes de ce framework.

IWHWI

Clean Architecture et abstraction CMS

IWHWI repose sur une Clean Architecture en quatre couches : Domain (entités, nœuds, champs), Infrastructure (adaptateurs CMS, sources de données), Interface (serveur MCP, commandes IA) et Usecase (façades, services). Le domaine métier est totalement découplé du CMS : l'adaptateur Directus implémente une interface générique (ICmsAdapter) que d'autres CMS pourront implémenter.

Content Types : une abstraction au-dessus du CMS

Les CMS headless comme Strapi ou Contentful intègrent nativement le concept de Content Type. Directus, en revanche, ne manipule que des collections et des champs individuels - sans couche d'abstraction. C'est pourquoi IWHWI a été conçu à partir de Directus, le cas le plus bas niveau, en introduisant les Content Types composés de Nodes (briques structurelles) et de Fields (champs métier). Par exemple, le Content Type « categories » se définit dans IWHWI avec 4 Nodes (1 init, 2 lang, 1 supp) et des champs additionnels. Sous Directus, cette définition se traduit automatiquement en 3 collections (categories, categories_base, categories_seo) avec toutes les relations nécessaires. Le Supp Node n'est pas une collection séparée : il ajoute un groupe de champs directement dans la collection principale. Cette abstraction, pensée pour le cas le plus complexe, sera d'autant plus simple à adapter aux CMS qui possèdent déjà ce concept.

Système de Nodes

  • Init Node : collection principale (identifiants, statut, métadonnées).
  • Lang Node : collections liées au Content Type languages (contenu traduit par langue).
  • Flag Node : collections liées au Content Type countries (configurations par pays).
  • Supp Node : groupes de champs ajoutés à la collection principale (images, paramètres).

Migration depuis les CMS traditionnels

Grâce à cette couche d'abstraction, IWHWI peut également servir de pont de migration entre les CMS traditionnels et les CMS headless modernes. L'objectif : récupérer le contenu structuré d'un site existant - WordPress, Joomla + Seblod, Joomla + K2, Joomla + FlexiContent ou Drupal + CCK - le mapper vers les Content Types IWHWI, puis le pousser vers le CMS headless cible (Directus, Strapi, Contentful...). Tous ces systèmes stockent des types de contenu avec des champs personnalisés, accessibles via leurs API REST ou leur base de données. IWHWI sera testé sur ces scénarios de migration pour valider cette approche.

Champs en trois couches

Les champs sont gérés indépendamment du CMS selon trois niveaux : Types (définitions de base des interfaces), Generics (champs métier réutilisables) et Specifics (champs spécifiques à un nœud). Chaque champ est un fichier séparé, importé et composé dans les nœuds.

Clean Architecture et abstraction CMS
Clean Architecture et abstraction CMS
Clean Architecture et abstraction CMS

Clean Architecture et abstraction CMS

IWHWI suit une Clean Architecture en quatre couches strictement découplées. La couche Domain définit les entités métier — Content Types, nœuds et champs — sans aucune dépendance vers un CMS. La couche Usecase orchestre les opérations (création de structures, synchronisation, traduction). L'Infrastructure fournit les adaptateurs concrets. L'Interface expose les commandes via MCP.

Ce découplage garantit que le modèle de contenu reste valide quel que soit le CMS sous-jacent.

L'adaptateur Directus implémente une interface générique (ICmsAdapter) avec des méthodes comme iwiCreateCollection, iwiCreateField, iwiReadItems. Demain, un adaptateur Strapi ou Contentful pourra implémenter la même interface. Le domaine métier, les nœuds et les champs restent identiques : seul l'adaptateur change.

Votre investissement dans la modélisation de contenu est protégé, indépendamment de l'évolution du marché des CMS.

Les champs sont gérés en trois couches indépendantes du CMS. Les Types définissent les interfaces de base (input, dropdown, boolean, file). Les Generics fournissent des champs métier réutilisables (titre, slug, statut, image). Les Specifics créent des champs dédiés à un contexte précis. Chaque champ est un fichier séparé, composé dans les nœuds via getDefinition().

Ce système garantit réutilisabilité, cohérence et maintenabilité des définitions de champs.

Content Types, Nodes et modélisation

Un Content Type IWHWI n'est pas une simple collection : c'est un ensemble cohérent de collections, de champs et de relations. Le Content Type « pages » crée automatiquement la collection principale (pages), les collections de langue (pages_base, pages_content, pages_seo), les groupes de champs (image, hero, paramètres) et toutes les relations M2O nécessaires.

Cette orchestration automatisée élimine les erreurs manuelles et garantit la cohérence structurelle.

Les Nodes sont des concepts propres à IWHWI — ils n'existent pas dans Directus. Un Init Node définit la collection principale. Les Lang Nodes créent des collections liées au Content Type languages (une entrée par langue). Les Flag Nodes créent des collections liées au Content Type countries (une configuration par pays). Les Supp Nodes ajoutent des groupes de champs à la collection principale.

Langues et pays sont eux-mêmes des Content Types IWHWI, créant un écosystème cohérent et auto-référent.

Content Types, Nodes et modélisation
Content Types, Nodes et modélisation
Content Types, Nodes et modélisation

Le mécanisme de fusion intelligent combine les données de trois sources (default, directus, ia) selon des stratégies adaptées à chaque type de nœud. Les Init Nodes utilisent une sélection stricte par priorité. Les Lang Nodes fusionnent au niveau des propriétés individuelles par langue. Les Supp Nodes appliquent des règles métier spécifiques. L'ordre de priorité est configurable selon le contexte.

Ce mécanisme garantit la cohérence des données tout en permettant l'intégration de contenu généré par IA.

Pilotage par IA et workflow MCP
Pilotage par IA et workflow MCP
Pilotage par IA et workflow MCP

Pilotage par IA et workflow MCP

Le protocole MCP (Model Context Protocol) permet à un assistant IA d'exécuter des actions sur des systèmes externes. IWHWI implémente un serveur MCP qui expose l'ensemble de ses commandes : structure (créer/supprimer des ensembles de collections), source (créer, mettre à jour, synchroniser les données), translate (traduction automatique), local (traductions d'interface), node (créer de nouveaux nœuds).

L'IA ne suggère pas : elle exécute directement les opérations sur votre modèle de contenu.

Le workflow source/sync gère le cycle de vie des données dans des dossiers versionnés (aXXXX). Trois espaces coexistent : default (référence figée), directus (état synchronisé du CMS) et ia (contenu généré par IA). Les commandes new, source create, sync, translate et source set forment un cycle complet. Chaque fichier JSON est horodaté et versionné dans Git.

Ce workflow rend chaque modification traçable, réversible et reproductible.

La traduction automatique détecte les contenus manquants par langue et les génère via Gemini ou Google Cloud Translate. IWHWI génère automatiquement les types TypeScript à partir des schémas de Content Types. Le framework supporte plusieurs environnements (alpha, production) avec des profils dédiés. Ajouter un nouveau Content Type se fait de façon déclarative : champs, nœuds, Content Type, puis une commande structure init.

Le résultat : un pipeline de contenu industrialisé, typé et piloté par l'intelligence artificielle.

En choisissant IWHWI pour la gestion de vos contenus, vous bénéficiez de :

  • un framework Clean Architecture qui modélise vos contenus indépendamment du CMS,
  • des Content Types multi-collections avec nœuds, champs et relations automatisés,
  • un pilotage complet par IA via le protocole MCP (création, synchronisation, traduction),
  • une architecture extensible : nouveaux CMS, nouveaux Content Types, nouvelles langues et pays,
  • un pont de migration pour récupérer le contenu de CMS traditionnels (WordPress, Joomla + Seblod/K2/FlexiContent, Drupal + CCK) vers un headless moderne.

IWHWI transforme la gestion de contenu en un processus industrialisé, CMS-agnostique et piloté par l'intelligence artificielle. Contactez-nous pour une démonstration.