Un client agence nous a demandé un outil interne permettant à ses graphistes, sans compétence technique, de décrire en langage naturel une mise en page et d’obtenir un pattern de blocs Gutenberg prêt à insérer dans une page. L’idée séduit vite, jusqu’à ce qu’on réalise qu’un modèle de langage ne produit pas toujours un markup de blocs valide, même quand le résultat semble correct à l’œil. Cet article ne traite pas de la conversion de contenus existants vers des blocs, un sujet différent : ici, la génération part de zéro, à partir d’une description textuelle.
Voici comment nous avons construit la chaîne complète, de la génération à l’intégration, avec un validateur qui rejette systématiquement ce qui ne peut pas s’afficher correctement.
Pourquoi un pattern généré peut sembler bon et être cassé
Le format des blocs Gutenberg repose sur des commentaires HTML délimitant chaque bloc, avec des attributs encodés en JSON à l’intérieur du commentaire. Un modèle de langage peut produire un HTML visuellement cohérent tout en cassant subtilement ce format : une virgule en trop dans le JSON d’attributs, un bloc parent non refermé, une imbrication de colonnes qui ne respecte pas la structure attendue par core/columns. Ces erreurs ne se voient pas en lisant le texte généré, seulement en le faisant parser réellement par WordPress.
La génération, avec un prompt contraint
Nous demandons systématiquement au modèle de ne produire que des blocs natifs courants, core/heading, core/paragraph, core/columns, core/image, core/buttons, en interdisant explicitement l’invention de blocs personnalisés inexistants dans le thème cible, et en fournissant un exemple de syntaxe correcte directement dans le prompt.
La validation avec parse_blocks
Une fois le markup généré, nous le passons systématiquement à parse_blocks côté serveur avant toute intégration. Cette fonction native décompose le contenu en tableau de blocs structurés ; un bloc dont le nom est vide ou dont les attributs ne se décodent pas correctement signale un problème de génération à corriger, jamais à afficher tel quel.
function valider_pattern_genere( string $markup ): array {
$blocs = parse_blocks( $markup );
$erreurs = array();
foreach ( $blocs as $index => $bloc ) {
if ( null === $bloc['blockName'] ) {
$erreurs[] = "Bloc {$index} : contenu orphelin hors de tout bloc reconnu.";
continue;
}
if ( ! str_starts_with( $bloc['blockName'], 'core/' ) ) {
$erreurs[] = "Bloc {$index} : type non autorisé ({$bloc['blockName']}).";
}
if ( ! empty( $bloc['innerBlocks'] ) ) {
foreach ( $bloc['innerBlocks'] as $sous_bloc ) {
if ( null === $sous_bloc['blockName'] ) {
$erreurs[] = "Bloc {$index} : sous-bloc invalide détecté.";
}
}
}
}
return $erreurs;
}
Que faire d’un pattern rejeté
Sur nos six premiers tests, un pattern sur six a été rejeté par ce validateur, à cause d’une balise de colonne non refermée correctement. Plutôt que de tenter une correction automatique du markup, ce qui risque d’introduire une erreur silencieuse, nous renvoyons directement le pattern au modèle avec la liste précise des erreurs détectées, en lui demandant une nouvelle génération corrigée. Cette boucle de correction automatique a résolu tous les cas testés en une seule itération supplémentaire.
L’intégration finale au thème
Une fois validé, le pattern est enregistré via register_block_pattern dans un répertoire dédié aux patterns générés, distinct des patterns créés manuellement par l’équipe, pour garder une trace claire de leur origine et faciliter un nettoyage ultérieur si nécessaire.
- Contraindre le prompt aux blocs natifs réellement supportés par le thème
- Toujours valider avec
parse_blocksavant toute intégration - Renvoyer les erreurs précises au modèle plutôt que de corriger le markup à la main
- Séparer les patterns générés des patterns créés manuellement dans le thème
Un markup qui ressemble à du Gutenberg valide n’est pas du Gutenberg valide. Seul le parseur natif de WordPress fait foi.
En résumé
Automatiser la création de patterns par IA fonctionne, à condition de ne jamais faire confiance au texte généré sans un passage par le parseur réel de WordPress. Cette étape de validation, simple à mettre en place, transforme un outil fragile en outil fiable que des utilisateurs non techniques peuvent réellement utiliser sans risque de casser une page.
