Pourquoi un blog en blocs typés bat le WYSIWYG

Tu écris un article, tu cliques sur gras, tu colles une image, tu publies. Trois mois plus tard, tu veux ce même contenu dans une newsletter et un flux RSS, et là c'est le drame : des `<span style>` Word collés à l'arrache, un tableau qui pète en mobile, un titre h1 dupliqué qui flingue ton SEO. Le problème n'est pas ton éditeur — c'est que tu stockes du HTML libre au lieu de stocker de la donnée.

Chez Zylior on traite chaque article comme une liste de blocs typés validés, pas une soupe HTML. Ça change tout : un seul contenu rend en page web, en email et en texte brut, sans jamais casser. Voici pourquoi ce modèle bat le WYSIWYG, avec le détail technique.

Le WYSIWYG stocke du HTML, et le HTML dérive

Un éditeur WYSIWYG produit une string HTML que tu ranges en base. Le souci : cette string est non contrainte. Rien n'empêche un `<div>` orphelin, un `style="font-family:Calibri"` collé depuis Word, un `<h1>` au milieu du corps, ou une balise jamais fermée. Tu ne le vois pas dans l'éditeur — il "corrige" silencieusement à l'affichage — mais le jour où tu sors ce HTML de son contexte (email, app mobile, API), il casse.

• Styles inline parasites : un copier-coller depuis Word/Notion injecte des `mso-*`, des couleurs en dur, des `<o:p>`. Ton thème ne contrôle plus rien.
• Structure invalide : `<h1>` dupliqué, `<h3>` sans `<h2>` parent → hiérarchie cassée pour le SEO et les lecteurs d'écran.
• HTML qui ne survit pas à l'email : Gmail strippe la moitié de tes balises, ton `<figure>` devient illisible.
• Aucune garantie de re-render : le même HTML rendu par deux moteurs (web vs client mail) donne deux résultats différents.

Un article = de la data validée, pas du markup

L'alternative : tu ne stockes jamais de HTML, mais un tableau de blocs typés, chacun avec une forme connue validée à l'écriture. Un paragraphe, c'est `{type:"p", text}` ; un titre de section, `{type:"h2", text}`. L'inline est restreint à une whitelist (`gras`, `italique`, liens https). Tout ce qui n'entre pas dans le schéma est rejeté à la sauvegarde, pas "toléré à l'affichage".

{
  "meta_title": "Blocs typés > WYSIWYG",
  "blocks": [
    { "type": "p", "text": "Accroche en **gras** et [un lien](https://zylior.com)." },
    { "type": "h2", "text": "Une section" },
    { "type": "list", "ordered": false, "items": ["Item 1", "Item 2"] },
    { "type": "callout", "tone": "tip", "text": "Un encadré." }
  ]
}

À partir de là, tu valides avec un schéma (Zod, JSON Schema, peu importe) : `type` dans l'enum, `text` borné à N caractères, `items` un tableau de strings, `tone` dans `{info,warn,tip}`. Un article invalide ne peut pas être sauvegardé. Tu déplaces la rigueur de l'affichage vers l'écriture — là où une erreur coûte un message d'erreur, pas une page cassée en prod.

Un seul contenu, trois rendus garantis

C'est le vrai gain opérationnel pour un solo-founder. Comme un bloc est de la data sémantique ("ceci est un titre", "ceci est une liste") et pas du markup, tu écris un renderer par cible et chaque bloc sait se rendre partout :

1. Web : `h2` → `<h2 class="...">` avec ton design system, `code` → coloration syntaxique.
2. Email : le même `h2` → table HTML inline-stylée compatible Gmail/Outlook ; les types interdits ne risquent même pas d'arriver.
3. Texte brut / RSS / LLM : `h2` → `## Titre`, `list` → puces markdown. Parfait pour résumer un article à un agent ou alimenter un digest.
4. JSON-LD : tu dérives automatiquement `articleBody`, `headline`, `wordCount` depuis les blocs, sans parser du HTML.

Aperçu = publié, et SEO réellement maîtrisé

Avec du HTML libre, ton aperçu utilise souvent un moteur de rendu différent de la prod (l'éditeur vs le site) : ce que tu vois n'est pas ce qui sort. Avec des blocs typés, l'aperçu appelle exactement le même renderer web que la publication. Zéro surprise : si l'aperçu est bon, le publié est identique. Côté SEO, comme la structure est garantie, tu contrôles ce que le WYSIWYG laisse dériver : un seul `h1` (issu de `meta_title`, jamais dans le corps), une hiérarchie `h2`/`h3` cohérente, une `meta description` bornée à 140-160 caractères, un `canonical` propre, et un `JSON-LD` de type `Article` dérivé mécaniquement des blocs. Ton markup est valide par construction, pas par espoir.

Pour être honnête, ce n'est pas gratuit : tu maintiens tes renderers et l'éditeur est plus contraint qu'un WYSIWYG "tout est permis" (pas de collage Word magique). Pour un blog de portfolio SaaS où tu veux fiabilité et multi-canal, c'est le bon compromis. Concrètement, pour démarrer : définis un enum de types (`p`, `h2`, `h3`, `list`, `code`, `callout`, `quote`), écris un schéma qui rejette tout le reste, branche un renderer web et un renderer texte (l'email vient après), et fais pointer ton aperçu sur le renderer web de prod. Tu auras un blog où l'aperçu ne ment jamais, où le même article part en newsletter sans retouche, et où ton SEO est correct par défaut — pas par vigilance manuelle.