Tu fais rédiger tes articles par une IA connectée directement à ton WordPress, et le brouillon arrive bien dans l’éditeur — sauf qu’au lieu de blocs distincts (un paragraphe, un titre, une liste, une citation), tu te retrouves avec un seul pavé de texte figé : le fameux bloc Classic.
Ce qui ne t’arrange pas pour la suite, comme insérer des CTA ou d’autres blocs synchronisés
voici comment je l’ai corrigé.
Le symptôme : ton article IA atterrit en un seul bloc Classic
L’article était bien là, avec ses titres et ses paragraphes visibles à l’écran. Mais dans l’éditeur, impossible de cliquer sur un H2 isolément ou de déplacer une liste : tout était fusionné dans un seul bloc «Classic», l’ancien format WordPress d’avant Gutenberg.
Pourquoi ça arrive
Le problème vient de la façon dont le contenu est envoyé à WordPress. Une IA rédactrice qui publie via une API ou un connecteur envoie généralement du HTML brut : des balises <p>, <h2>, <ul>, sans rien d’autre. WordPress accepte ce HTML sans broncher — mais comme il ne trouve aucune indication de découpage en blocs, il range tout le paquet dans un seul bloc Classic.
faire ajouter les commentaires de blocs Gutenberg natifs
Le format que WordPress attend
Gutenberg, l’éditeur en blocs de WordPress, reconnaît la structure d’un contenu grâce à des commentaires HTML invisibles à la publication, placés autour de chaque élément. Chaque type de bloc a son marqueur : wp:paragraph pour un paragraphe, wp:heading pour un titre, wp:list pour une liste, wp:quote pour une citation. Sans ces marqueurs, même un HTML parfaitement propre reste un bloc unique aux yeux de WordPress.
Exemple concret : avant / après
Voici ce qui a changé sur mon propre brouillon. Avant, le contenu envoyé ressemblait à ça :
<h2>Pourquoi le ciblage n'est pas (toujours) le vrai problème</h2>
<p>Quand le taux de conversion...</p>Après correction, le même contenu a été renvoyé avec les marqueurs de blocs autour de chaque élément :
<!-- wp:heading -->
<h2>Pourquoi le ciblage n'est pas (toujours) le vrai problème</h2>
<!-- /wp:heading -->
<!-- wp:paragraph -->
<p>Quand le taux de conversion...</p>
<!-- /wp:paragraph -->Le rendu visible sur le site ne change absolument rien — ces commentaires sont invisibles côté public. La différence se joue entièrement côté éditeur : chaque paragraphe, titre, liste ou citation redevient un bloc à part entière, déplaçable et modifiable indépendamment du reste.
Comment vérifier que ça a marché
Le test est simple : ouvre le brouillon dans l’éditeur WordPress et clique sur un paragraphe. S’il se sélectionne seul, avec sa propre bordure de bloc et sa propre barre d’outils, c’est bon. Si tout le texte se sélectionne d’un coup dans un seul cadre gris «Classic», les marqueurs de blocs manquent encore dans le contenu envoyé.
Rendre le fix permanent : le noter dans le process de ton IA
Corriger un article une fois ne suffit pas — sans consigne écrite quelque part, rien ne garantit que la prochaine génération respecte le même format. Deux endroits différents permettent de fixer une règle de ce type, et ils ne jouent pas le même rôle.
Instructions de projet vs mémoire
Les instructions du projet sont le texte que tu configures toi-même dans les réglages de ton espace de travail IA. C’est l’endroit pour une règle stricte et visible, du type : « le contenu envoyé sur WordPress doit toujours être formaté en blocs Gutenberg natifs, jamais en HTML classique brut ». Seul toi peux les modifier — l’IA n’y a pas accès en écriture.
La mémoire de session (ou mémoire de projet, selon l’outil) est un espace que l’IA peut écrire elle-même et qui persiste d’une conversation à l’autre. C’est là que je fais consigner les corrections de process au fur et à mesure — comme celle du format de blocs — pour qu’elles s’appliquent automatiquement la fois suivante, sans avoir à tout réexpliquer.
Dans mon cas, j’ai fait créé par claude un fichier md livraison qui sera mis à jour au fur et à mesurer d’améliorer mon process.
