Coller du HTML dans Elementor en toute sécurité : ce qui est supprimé, et pourquoi

Coller du HTML dans un site WordPress en production est un acte de confiance, surtout quand ce HTML provient d’un modèle, d’une IA ou de la page de quelqu’un d’autre. La méthode la plus sûre n’est pas la prudence — c’est de savoir exactement ce qui est supprimé avant que quoi que ce soit n’atteigne votre éditeur. Voici cette liste, et les pratiques qui couvrent le reste.

Ce qui est supprimé avant même que vous ne colliez

La conversion s’exécute entièrement dans votre navigateur, et le résultat est constitué de données Elementor — pas du balisage d’origine. Au passage, les éléments suivants sont supprimés ou neutralisés :

• Toutes les balises script. Aucun JavaScript de la source ne survit, point final. Tout ce qui est interactif arrive sous forme de balisage statique, à reconstruire avec les widgets propres à Elementor.
• Tous les gestionnaires d’événements en ligne. Les attributs comme onclick et onmouseover sont retirés de chaque élément individuellement — la manière classique de faire passer du script dans un balisage qui « ne contient aucune balise script ».
• Les destinations des formulaires. Les attributs action et method d’un formulaire sont supprimés. Les champs visibles restent, mais un formulaire collé ne pourra jamais envoyer discrètement les données de vos visiteurs à l’auteur de la page d’origine.
• Les intégrations inconnues. Les balises object, embed et applet sont bloquées. Les iframes ne sont autorisées que depuis quatre hôtes exactement — YouTube, sa variante nocookie et le lecteur Vimeo — et deviennent des widgets Vidéo ; toute autre iframe n’est pas conservée comme cadre actif. L’attribut srcdoc, qui peut cacher un document entier dans une balise iframe, est supprimé lui aussi.
• Les cibles de liens dangereuses et le CSS risqué. Les cibles de liens et les déclarations de style sont nettoyées plutôt que copiées telles quelles.

Tout ce qui est supprimé figure dans le rapport de sécurité de l’écran de résultat ; il ne s’agit donc pas d’une règle appliquée en silence — vous pouvez lire exactement ce qui a été retiré de votre page avant de la coller.

Pourquoi le CSS ne peut pas fuir vers votre thème

Le risque le plus subtil, quand on colle du HTML stylé, n’est pas la malveillance mais la collision : la feuille de style de la page source déclare body { font-family: … } ou h2 { color: … }, et ces règles modifient l’apparence de tout votre site.

Pour l’éviter, les styles conservés sont cloisonnés. Chaque sélecteur du CSS importé est réécrit pour ne s’appliquer qu’à l’intérieur du contenu importé — et les sélecteurs qui ciblent html, body ou :root sont redirigés vers le bloc importé lui-même au lieu de pouvoir atteindre votre page. La section importée conserve son apparence ; votre thème ne voit jamais ces règles.

C’est le même raisonnement qui explique pourquoi position: fixed est rétrogradé en absolute lors de la conversion : sans cela, un élément fixe issu de la page de quelqu’un d’autre flotterait au-dessus de tout votre site, sur chaque page utilisant le modèle.

Ce que « sûr » ne veut pas dire

Deux limites, en toute honnêteté. Premièrement, l’outil ne peut pas vérifier votre contenu — si le HTML contient des textes, des images ou des liens sur lesquels vous ne détenez pas les droits, le convertir n’y change rien. Deuxièmement, la suppression concerne ce qui s’exécute et la destination des données ; elle n’examine pas ce que la page dit. Lisez ce que vous collez.

Bonnes pratiques avant de coller

• Convertissez, ne collez jamais le code brut. La voie dangereuse consiste à coller tel quel du balisage tiers dans un widget HTML — ce chemin ne comporte aucune suppression et embarque tout ce que contenait la source. La conversion en widgets natifs constitue la couche de sécurité.
• Lisez le rapport de sécurité sur l’écran de résultat. S’il indique quatre scripts supprimés et un formulaire nettoyé, vous savez quels comportements vous devez reconstruire — et ce que faisait la page d’origine.
• Collez d’abord dans un brouillon. Non pas parce que la conversion est risquée, mais parce que la vérification de la mise en page doit se faire sur une page que personne ne visite.
• Reconnectez les formulaires en connaissance de cause. La destination d’envoi a été supprimée volontairement ; reliez le widget Formulaire d’Elementor à vos propres actions plutôt que de chercher la destination d’origine.
• Conservez des sauvegardes dans tous les cas. Un conseil standard pour toute importation, quelle qu’elle soit et quel que soit l’outil.

Et votre propre HTML ne quitte jamais votre navigateur

La sécurité joue aussi dans l’autre sens. La page que vous convertissez est analysée, rendue et convertie localement — votre HTML et vos images ne sont envoyés ni sur ce site ni ailleurs, il n’existe aucun compte susceptible de fuiter, et rien ne touche à vos identifiants WordPress. L’outil produit des données ; c’est vous qui décidez de ce qu’elles deviennent, dans votre propre éditeur.

La méthode la plus sûre, en un paragraphe

Convertissez en mode composants natifs plutôt que de coller du HTML brut dans un widget. Lisez le rapport de sécurité. Collez dans un brouillon, reconstruisez les parties interactives avec les widgets propres à Elementor, reconnectez le formulaire à votre site, et publiez une fois que le rendu est correct aux trois points de rupture. Voilà toute la méthode — la suppression décrite plus haut s’occupe de la partie que vous ne voyez pas, et la liste de contrôle s’occupe de celle que vous voyez.