Chaque outil de conversion a ses limites. Les connaître à l’avance transforme une mauvaise surprise en une tâche planifiée de cinq minutes.
Scripts et interactivité
Toutes les balises script sont supprimées. C’est un choix de sécurité : importer du JavaScript arbitraire dans votre site via un copier-coller serait dangereux, et cela ne fonctionnerait de toute façon pas de manière fiable dans l’éditeur. Tout ce qui repose sur du JS personnalisé (sliders, onglets, compteurs, accordéons) arrive sous forme de balisage statique.
Que faire : reconstruisez l’interaction avec le widget Elementor correspondant. Les onglets, accordéons, carrousels, compteurs et barres de progression existent tous nativement et sont plus faciles à maintenir que des scripts importés.
Formulaires
L’action d’envoi et la méthode d’un formulaire sont supprimées, tandis que les champs visibles sont conservés. Un formulaire qui envoie des données quelque part est une intégration, pas du balisage : conserver l’endpoint enverrait silencieusement les données de vos visiteurs vers le serveur de quelqu’un d’autre.
Que faire : associez-le à un widget Formulaire Elementor et configurez les actions (e-mail, webhook, intégrations) sur votre propre site.
Menus de navigation
Une navigation peut produire un widget Menu de navigation, mais le widget doit être relié à un vrai menu WordPress. Il est impossible de déduire la structure du menu de votre site à partir du balisage de quelqu’un d’autre.
Pseudo-éléments
Les pseudo-éléments ::before et ::after ne sont pas des nœuds DOM. Les formes décoratives, guillemets, superpositions en dégradé et soulignements d’accent dessinés ainsi n’existent tout simplement pas en tant qu’éléments et ne peuvent pas devenir des widgets. Si un détail de conception manque après la conversion, un pseudo-élément est le premier suspect.
Animations, transitions et comportement sticky
Les animations par images clés, les effets de défilement, les transitions et le positionnement sticky ne sont pas repris. Elementor possède ses propres commandes d’effets de mouvement et de sticky, qui sont de toute façon mieux intégrées à l’éditeur.
Intégrations tierces
Seuls les iframes YouTube et Vimeo sont conservés — tout le reste est supprimé plutôt que d’importer un cadre inconnu. Les balises object et embed sont également supprimées.
États de survol et de focus
Seul l’état de repos d’un élément peut être lu. Les couleurs de survol, les anneaux de focus et les états actifs doivent être réappliqués dans Elementor.
Images Base64 et chemins locaux
Les images en data URL et les chemins de fichiers relatifs ne peuvent pas devenir des pièces jointes de la bibliothèque de médias ; ils sont donc transformés en emplacements d’image vides, avec le texte alternatif d’origine conservé comme légende afin que vous sachiez quelle image va où.
Les propriétés personnalisées CSS arrivent aplaties
Si votre source utilise des design tokens — --brand-500, --space-4, etc. — les variables elles-mêmes ne survivent pas. Le convertisseur lit les styles calculés, et au moment où un style est calculé, le navigateur a déjà résolu chaque référence var() en une valeur littérale. Un bouton dont l’arrière-plan est var(--brand-500) est converti avec la couleur que cette variable contenait à ce moment-là, et non comme une référence à celle-ci.
Rien ne semble anormal ensuite, et c’est exactement ce qui piège : la page s’affiche correctement, mais la propriété qui rendait votre système de conception maintenable a disparu. Changez la couleur de marque plus tard et vous modifierez trente widgets à la main.
Que faire : reconstruisez la couche de tokens côté Elementor. Définissez votre palette dans les couleurs globales et votre échelle typographique dans les polices globales avant de coller, puis réassignez les widgets importés à ces valeurs globales. Vous ne le faites qu’une fois, et vous retrouvez le comportement de source unique de vérité. Le convertisseur dispose précisément d’un mode Couleurs du site et Polices du site pour cela : il laisse de côté la couleur et la typographie des widgets importés afin qu’ils héritent de vos globales Elementor au lieu d’arriver codés en dur.
Zones de grille nommées
Les mises en page en grille se convertissent via les paramètres de colonnes et d’espacements : grid-template-columns correspond à un conteneur Grille Elementor, et les unités fractionnaires sont préservées. Ce qui ne se transpose pas, c’est grid-template-areas — la syntaxe de régions nommées où vous dessinez la mise en page comme un petit schéma ASCII et attribuez un nom à chaque enfant.
Le conteneur Grille d’Elementor n’a pas d’équivalent aux zones nommées, donc une mise en page construite ainsi perd son placement et les enfants reviennent à l’ordre normal du code source. Le résultat n’est pas cassé, mais ce n’est pas non plus votre mise en page.
Que faire : si vous contrôlez la source, exprimez la mise en page avec grid-template-columns et des étendues explicites plutôt que des zones nommées. Sinon, attendez-vous à devoir repositionner les enfants une fois dans Elementor.
Le positionnement fixe est volontairement rétrogradé
Tout élément avec position: fixed est réécrit en position: absolute pendant la conversion, et le rapport de sécurité vous indique que cela s’est produit. C’est l’un des rares cas où l’outil modifie intentionnellement votre conception plutôt que de la reproduire.
La raison est le confinement. Un élément fixe est positionné par rapport à la fenêtre du navigateur, pas par rapport à son parent. Ainsi, un en-tête fixe, une barre de cookies sticky ou une bulle de discussion flottante importés depuis la page de quelqu’un d’autre s’échapperaient de la section dans laquelle vous les avez collés et flotteraient sur tout votre site, sur chaque page utilisant le modèle. La rétrogradation en absolu le maintient à l’intérieur du bloc importé, là où vous pouvez le voir et décider quoi faire.
Que faire : si vous voulez vraiment que l’élément soit fixe, configurez-le avec les commandes sticky d’Elementor après l’importation. Elles tiennent compte de l’éditeur, de la barre d’administration et de votre en-tête, ce qu’une règle CSS brute ne fait pas.
Polices web : le nom voyage, les fichiers non
La typographie est convertie sous forme de valeurs — nom de famille, taille, graisse, hauteur de ligne, espacement des lettres — et celles-ci arrivent dans les commandes de typographie d’Elementor. Les fichiers de police sont une autre affaire. Une règle @font-face pointe vers des fichiers woff2 hébergés sur le site source ; rien ne les copie sur votre serveur et rien n’enregistre la famille auprès de WordPress.
Ainsi, un titre converti à partir d’une page utilisant une police auto-hébergée portera le bon nom de famille, puis retombera sur ce que votre site possède réellement. Le rendu est généralement assez proche pour que vous ne le remarquiez pas tant que vous ne comparez pas côte à côte.
Que faire : installez d’abord la police sur votre propre site — via les polices personnalisées d’Elementor, une sélection Google Fonts ou votre thème — puis convertissez seulement ensuite. Si la famille est déjà disponible, la typographie importée s’aligne immédiatement.
Comment savoir quelle limite vous avez atteinte
Vous n’avez pas besoin de deviner. Deux éléments de la vue de résultat répondent directement à la question :
- Le rapport de sécurité liste ce qui a été supprimé ou réécrit : scripts retirés, actions de formulaire nettoyées, intégrations écartées, réécriture de fixe en absolu, images Base64 abandonnées. Si un détail a disparu, il est en général nommé ici.
- La carte de structure montre l’arborescence Elementor à côté d’un aperçu en direct, les deux se mettant en surbrillance mutuellement au survol. Tout ce qui est arrivé sous forme de bloc rouge de widget HTML n’avait pas d’équivalent natif — survolez-le et vous verrez exactement de quelle partie de la page il s’agissait.
Ensemble, la question cesse d’être « pourquoi est-ce différent ? » et devient « cet élément précis a été traité de cette manière précise », ce qui représente une correction de deux minutes au lieu d’un après-midi.
Le résumé honnête
La structure, le texte, les images, les icônes, les couleurs, les espacements et la typographie se convertissent bien. Les comportements, les intégrations, tout ce qui n’est pas présent dans le DOM et tout ce qui dépend de fichiers ou de données hébergés sur le serveur source ne se convertissent pas. Prévoyez une courte passe post-importation couvrant les formulaires, les menus, les états de survol, les animations et les polices, et le processus devient prévisible plutôt que surprenant.