Générer une page avec un assistant IA ou exporter du HTML depuis un outil de design vous amène une bonne partie du chemin. Transformer cela en une page Elementor maintenable est un processus court et reproductible.
Étape 1 — Réglez d’abord la question des images
C’est l’étape que les gens sautent, et c’est elle qui cause le plus de reprise. L’IA ne peut pas intégrer de vraies photographies dans du HTML, et les exports d’outils de design utilisent souvent des chemins locaux ou des URL de données — aucun de ces éléments ne peut devenir des pièces jointes de la bibliothèque de médias.
Deux bonnes options : importez d’abord vos images dans la bibliothèque de médias et référencez les vraies URL dans le HTML, ou acceptez des espaces réservés vides et remplissez-les dans Elementor par la suite. Si vous optez pour les espaces réservés, assurez-vous que chaque image possède un attribut alt significatif — ce texte est conservé comme légende de l’emplacement, afin que vous sachiez quelle image va où.
Étape 2 — Demandez un balisage facile à convertir
Si vous utilisez une requête à un modèle, dites ce dont vous avez besoin : des balises sémantiques, un DOM peu profond avec un seul conteneur par section, tout le CSS dans un seul bloc de style, des classes d’icônes Font Awesome plutôt que du SVG en ligne, et aucun script ni police externe. Ces quelques contraintes ont un effet plus important sur le résultat que tout ce que vous pourrez faire par la suite.
Étape 3 — Convertissez avec les bonnes options
- Mode composants natifs, pour obtenir des widgets modifiables plutôt qu’un seul bloc HTML.
- Icônes : faites correspondre à la bibliothèque d’icônes d’Elementor, pour que les icônes deviennent de vraies icônes interchangeables.
- Couleurs et polices : utilisez les valeurs du site s’il s’agit d’un site de marque, ou les valeurs d’origine si vous reproduisez un design.
- Images : des espaces réservés vides, sauf si vous avez déjà de vraies URL.
Étape 4 — Vérifiez la structure avant d’exporter
Ouvrez la carte de structure. Regardez le nombre de composants, la profondeur d’imbrication maximale et la répartition de la confiance. Les lignes rouges ont été conservées en HTML et méritent un examen. Si la profondeur est élevée, définissez une racine de copie plus profonde dans l’arborescence ou simplifiez la source et convertissez à nouveau — corriger l’entrée est presque toujours plus rapide que réparer la sortie.
Étape 5 — Collez et finalisez
Collez dans Elementor, puis effectuez la passe de finition standard : réattribuez les liens aux boutons, définissez les états de survol, connectez tout formulaire ou menu, importez les images des espaces réservés, et parcourez les versions bureau, tablette et mobile.
Étape 6 — Mettez de côté les éléments réutilisables
Tout ce que vous réutiliserez — une ligne de tarification, une grille de fonctionnalités, un bloc de témoignage — enregistrez-le immédiatement dans la bibliothèque de modèles. Au fil de quelques projets, cela devient une bibliothèque de composants qui rend la prochaine construction beaucoup plus rapide, et cela vaut plus que n’importe quelle page convertie isolément.
Les quatre instructions qui comptent le plus dans une requête
C’est à l’étape 2 que se décide l’essentiel du résultat ; il vaut donc la peine d’être précis sur les instructions qui changent réellement le résultat. En ordre approximatif d’impact :
- « N’intégrez pas les images sous forme d’URL de données Base64. » Livré à lui-même, un modèle auquel on demande une page autonome va intégrer chaque image en ligne, et une page de douze images dépasse allègrement le demi-mégaoctet. Ces images ne peuvent pas devenir des pièces jointes de la bibliothèque de médias, elles arrivent donc toutes comme des emplacements vides. Demandez plutôt une vraie URL hébergée ou un simple chemin d’espace réservé.
- « Utilisez des classes Font Awesome pour les icônes, pas de SVG en ligne. » Les noms de classes Font Awesome correspondent directement à la bibliothèque d’icônes d’Elementor sous forme de véritables icônes interchangeables. Un SVG en ligne dessiné à la main ne peut pas du tout entrer dans ce contrôle et reste sous forme de HTML brut. Cette seule ligne fait la différence entre des icônes modifiables et une page pleine de blocs HTML rouges.
- « Gardez un DOM plat — un seul conteneur par section, pas d’imbrication redondante. » Le convertisseur reflète votre balisage : l’imbrication en entrée égale l’imbrication en sortie. Les modèles produisent par défaut des imbrications profondes de div conteneurs, car c’est à cela que ressemblent la plupart des données d’entraînement.
- « Utilisez des balises sémantiques. » De vrais
<h1>–<h3>,<p>,<button>,<ul>. Les balises sémantiques correspondent aux widgets natifs ; une page entièrement construite à partir de div stylisées donne beaucoup moins de matière au convertisseur.
Des requêtes prêtes à l’emploi contenant ces quatre instructions se trouvent sur la page des requêtes IA, y compris une écrite spécifiquement pour le flux de travail axé sur les images d’abord.
Pourquoi les exports d’outils de design se comportent différemment de la sortie de l’IA
Les deux sources échouent dans des directions opposées, et savoir à laquelle vous avez affaire vous indique où chercher.
Le HTML généré par l’IA est généralement correct sur le plan sémantique — il utilise de vrais titres et paragraphes parce qu’il a été entraîné sur de la documentation. Ses faiblesses sont les images Base64 intégrées, les icônes SVG en ligne et plus de div conteneurs que nécessaire pour la mise en page. Ces trois problèmes sont corrigibles en modifiant la requête et en régénérant, ce qui ne prend que quelques secondes.
Les exports d’outils de design sont l’inverse. Les images et les ressources sont généralement référencées correctement, mais le balisage a tendance à être composé de div positionnées de manière absolue avec des noms de classes générés et aucune structure sémantique — parce que l’outil décrit un canevas, pas un document. Il n’y a souvent aucun élément de titre nulle part, de sorte que rien ne peut devenir un widget Titre.
Ce second cas n’est pas vraiment un problème de conversion. Une sortie de canevas en positionnement absolu ne correspond à aucune mise en page Elementor, et aucun outil ne peut déduire une structure de document qui n’a jamais été exprimée. Si votre export ressemble à cela, la réponse honnête est de reconstruire la structure plutôt que de la convertir — ou de retourner dans l’outil de design et d’exporter une version sémantique en flux normal, s’il en propose une.
Régénérez plutôt que de réparer
L’habitude qui rend ce processus rapide consiste à traiter la source comme jetable. Si la carte de structure indique une profondeur de 8 et six blocs HTML rouges, n’ouvrez pas Elementor pour commencer à corriger — ajoutez deux lignes à la requête, régénérez et convertissez à nouveau. Cette boucle prend environ une minute.
Réparer les mêmes problèmes dans Elementor prend une heure et doit être répété à la page suivante. Corriger la requête corrige chaque page que vous générez par la suite, ce qui est toute la raison pour laquelle ce flux de travail vaut la peine d’être mis en place.