# Convertir du HTML hérité en blocs Gutenberg grâce à un LLM

> Retour d'expérience sur une migration de contenus legacy vers du markup de blocs valide assisté par IA, avec taux d'échec réel et méthode de contrôle appliquée.

- Auteur : Clément Hadrot
- Publié le : 2024-10-04
- Mis à jour le : 2024-10-04
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/convertir-html-blocs-gutenberg-llm/

## L’essentiel

- Le HTML brut ne devient jamais des blocs sans validation
- Un taux d'échec incompressible à anticiper
- Toujours garder l'original en sauvegarde

Un cabinet d'expertise comptable en ligne depuis 2009 nous a confié la migration de son site vers un thème récent basé sur l'éditeur de blocs, avec plus de six cents pages rédigées en HTML brut dans l'éditeur classique, accumulées sur quinze ans par plusieurs webmasters successifs. Reconvertir ce volume manuellement en blocs Gutenberg valides aurait représenté plusieurs semaines de travail répétitif. Ce retour d'expérience porte sur la conversion assistée par IA que nous avons mise en place, ses résultats réels et ses limites.

Cet article ne traite pas la migration de shortcodes, un sujet nécessitant une approche différente puisqu'un shortcode encapsule une logique métier propre à l'extension qui l'a créé, que l'IA ne peut pas deviner sans contexte supplémentaire.

## Le principe : transformer, jamais publier sans passage humain

Le contenu HTML de chaque page était transmis au modèle avec une instruction précise : produire l'équivalent en syntaxe de commentaires de blocs Gutenberg, en respectant la structure sémantique du contenu d'origine plutôt que de tout transformer en un unique bloc HTML personnalisé, ce qui aurait annulé l'intérêt de la migration.

```
Convertis ce contenu HTML en blocs Gutenberg natifs.
Utilise wp:paragraph pour les paragraphes, wp:heading pour les titres,
wp:list pour les listes, wp:quote pour les citations.
Ne modifie ni le texte ni l'ordre du contenu.
Si une structure ne correspond à aucun bloc natif, encapsule-la
dans wp:html plutôt que de la déformer.
```

## Le format de sortie attendu

Le résultat attendu suit la syntaxe de commentaires que WordPress utilise en interne pour délimiter chaque bloc, avec ses attributs éventuels au format JSON dans le commentaire d'ouverture.

```
<!-- wp:heading -->
<h2>Nos domaines d'intervention</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Le cabinet accompagne les indépendants et TPE dans leurs
obligations comptables et fiscales depuis plus de quinze ans.</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><li>Tenue comptable</li><li>Déclarations fiscales</li></ul>
<!-- /wp:list -->
```

> L'essentiel à retenir : Le HTML brut ne devient jamais des blocs sans validation ; Un taux d'échec incompressible à anticiper ; Toujours garder l'original en sauvegarde

## Valider automatiquement avant tout enregistrement

WordPress fournit une fonction native pour vérifier la validité de blocs, que nous utilisons systématiquement avant d'enregistrer une conversion : elle repère les blocs mal formés qui provoqueraient un avertissement de récupération de contenu dans l'éditeur.

```
function wpm_valider_conversion_blocs( $contenu_converti ) {
    $blocs = parse_blocks( $contenu_converti );

    foreach ( $blocs as $bloc ) {
        if ( null === $bloc['blockName'] && ! empty( trim( $bloc['innerHTML'] ) ) ) {
            return false; // Contenu orphelin hors de tout bloc reconnu.
        }
    }

    return true;
}
```

Chaque page dont la conversion échoue à cette validation est automatiquement écartée du lot importé et signalée pour un traitement manuel, plutôt que forcée dans la base au risque de casser l'affichage public.

## Le taux d'échec réel constaté

Sur les six cent trente pages traitées, 12 % ont nécessité une correction manuelle après conversion, principalement des pages contenant des tableaux de tarifs mis en forme avec des styles en ligne complexes, ou des mises en page à plusieurs colonnes bricolées avec des balises `<div>` imbriquées que le modèle interprétait de façon incohérente d'une page à l'autre.

| Type de contenu source | Taux d'échec de conversion |
| --- | --- |
| Texte simple avec titres et paragraphes | Moins de 2 % |
| Listes et citations | Environ 5 % |
| Tableaux avec styles en ligne | Près de 30 % |
| Mises en page en colonnes avec div imbriquées | Plus de 40 % |

### La sauvegarde de l'original, une condition non négociable

Avant toute conversion, le contenu HTML d'origine de chaque page a été archivé intégralement dans une table personnalisée, indépendamment de la base de révisions standard de WordPress. Cette précaution a servi à plusieurs reprises pour retrouver rapidement la version source d'une page dont la conversion s'était révélée incorrecte après publication.

## La méthode de contrôle qualité appliquée

1. Conversion automatique de chaque page, en tâche de fond.
2. Validation technique via `parse_blocks()`, rejet automatique des échecs de structure.
3. Comparaison visuelle par capture d'écran entre la page d'origine et la page convertie, pour chaque page acceptée à l'étape précédente.
4. Revue manuelle de toutes les pages signalées comme visuellement différentes avant publication définitive.

> Une conversion qui produit un HTML syntaxiquement valide n'est pas forcément une conversion qui préserve l'apparence attendue par le client. Ces deux vérifications ne se substituent jamais l'une à l'autre.

## Le bilan de ce chantier

Sur l'ensemble du volume, le temps total de migration, correction manuelle comprise, a représenté environ un cinquième du temps qu'aurait demandé une reprise entièrement manuelle des six cent trente pages. Le point de vigilance à retenir pour un chantier comparable reste le même : anticiper un taux d'échec incompressible sur les contenus les plus mis en forme, plutôt que de viser une automatisation à 100 % qui ne se produira pas.