# Custom Code d’Elementor Pro : injecter des scripts sans toucher au thème > Utiliser la fonction Custom Code d'Elementor Pro pour injecter des scripts tiers avec conditions et priorité, et savoir quand préférer functions.php. - Auteur : Clément Hadrot - Publié le : 2024-08-12 - Mis à jour le : 2024-08-12 - Catégorie : Elementor - URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/custom-code-elementor-pro-injecter-scripts/ ## L’essentiel - Custom Code cible des emplacements précis sans éditer de fichier - Les conditions d'affichage reprennent le même moteur que le Theme Builder - Un script mal placé peut ralentir tout le site Sur un projet où le client changeait fréquemment d'outil de suivi marketing sans jamais impliquer un développeur, insérer chaque nouveau script directement dans le fichier `functions.php` du thème enfant était devenu une source d'erreurs de syntaxe et de conflits de merge. La fonction Custom Code d'Elementor Pro, accessible depuis **Elementor > Custom Code**, a permis de déplacer cette responsabilité vers une interface plus sûre, sans donner un accès direct au code du thème. Ce billet détaille comment cette fonctionnalité fonctionne réellement, ses réglages de priorité et de conditions, et dans quels cas il vaut mieux malgré tout revenir à `functions.php` ou à un plugin de fonctionnalités dédié. ## Créer un bloc de code personnalisé Chaque entrée Custom Code se compose d'un nom, d'un emplacement d'insertion, d'une priorité, et de conditions d'affichage identiques dans leur logique à celles du Theme Builder. Les emplacements disponibles sont l'en-tête (``), juste après l'ouverture de ``, juste avant sa fermeture, et un emplacement « body » plus générique. ``` ``` Sur ce projet, trois blocs distincts ont été créés : un pour la balise de mesure d'audience dans l'en-tête, un pour un pixel de réseau social juste après l'ouverture du `body`, et un troisième réservé au script d'un widget de chat, activé uniquement sur les pages de contact via les conditions d'affichage. ## Gérer la priorité entre plusieurs blocs Quand plusieurs scripts ciblent le même emplacement, l'ordre d'exécution peut avoir de l'importance, en particulier si un script dépend d'une variable définie par un autre. Le champ de priorité, un nombre entier, détermine cet ordre : plus la valeur est basse, plus le bloc s'exécute tôt. Sur ce projet, le script de mesure d'audience a reçu une priorité de 5 pour s'exécuter avant le pixel du réseau social, réglé à 10, qui dans certains cas s'appuyait sur une variable globale initialisée par le premier. > L'essentiel à retenir : Custom Code cible des emplacements précis sans éditer de fichier ; Les conditions d'affichage reprennent le même moteur que le Theme Builder ; Un script mal placé peut ralentir tout le site ## Cibler les bonnes pages avec les conditions Les conditions d'affichage de Custom Code utilisent le même système que le Theme Builder : toute la boutique, une catégorie de produits précise, une seule page, ou l'exclusion explicite d'un contenu. Pour le script de chat, la condition retenue a été **Inclure : Page : Contact**, ce qui évite de charger ce script sur l'ensemble du site alors qu'il n'a d'utilité que sur une seule page. ### Un piège fréquent : les conditions qui se chevauchent Avec plusieurs blocs de code actifs, il devient facile de perdre de vue quelles conditions se chevauchent, surtout après plusieurs mois d'ajouts successifs par différentes personnes. Sur ce site, un script de test A/B abandonné depuis longtemps continuait de se charger sur toutes les pages produit, ajouté par un ancien prestataire sans que personne ne s'en souvienne, jusqu'à ce qu'un audit de performance le révèle. Une revue trimestrielle de la liste des blocs Custom Code, avec suppression de ceux devenus inutiles, évite ce genre d'accumulation silencieuse. ## Quand préférer functions.php ou un plugin dédié - Code qui modifie un comportement PHP côté serveur (hooks WordPress, filtres WooCommerce) : Custom Code ne gère que du HTML et du JavaScript côté navigateur, pas du PHP exécuté côté serveur. - Logique complexe avec plusieurs fonctions qui s'appellent entre elles : un plugin de fonctionnalités reste plus lisible et plus facile à versionner dans Git qu'un ensemble de blocs Custom Code dispersés dans l'interface. - Script critique pour le fonctionnement du site (pas seulement du suivi marketing) : le dépendre d'Elementor Pro crée un couplage risqué si le plugin venait à être désactivé par erreur. ## Le risque de ralentissement mal maîtrisé Rien n'empêche techniquement d'activer un bloc Custom Code sur l'ensemble du site sans réfléchir à son poids. Un script de widget tiers volumineux, injecté sans condition dans l'en-tête de chaque page, retarde le rendu initial de tout le site, y compris sur les pages où ce widget n'est jamais utilisé. La discipline à adopter est la même qu'avec n'importe quel script tiers : le charger uniquement là où il sert, et vérifier son poids réel avant de l'ajouter en production. ## En résumé Custom Code d'Elementor Pro comble un vrai besoin opérationnel : permettre à une équipe non technique d'ajouter des scripts tiers courants sans ouvrir le code du thème, avec un ciblage par page fiable. Ce n'est cependant pas un substitut à un vrai plugin de fonctionnalités pour la logique métier du site, et sa simplicité d'usage peut, sans discipline, devenir une source d'accumulation de scripts oubliés qui pèsent sur la performance sans que personne ne s'en aperçoive.