vendredi 25 septembre 2026

À propos

Contact

Blocs Gutenberg

Charger la clé API d’une carte uniquement quand le bloc est présent

Ne pas exposer ni charger un script tiers coûteux sur des pages sans carte, en détectant la présence réelle du bloc avant d'injecter la clé et le script.

Par Clément Hadrot • 21 janvier 2025 • 4 min de lecture • Aucun commentaire
Charger la clé API d'une carte uniquement quand le bloc est présent

Le Cabinet Ferrand, un cabinet d’expertise comptable avec plusieurs implantations régionales, affiche une carte de localisation uniquement sur sa page « Nos agences ». Le bloc carte reposait sur un service cartographique tiers facturé au nombre de chargements de carte, une pratique commerciale qui rend chaque chargement inutile littéralement coûteux. Or le script du fournisseur et la clé API associée étaient chargés globalement, sur les cent et quelques pages du site, y compris celles qui ne contenaient jamais ce bloc.

Cet article ne revient pas sur l’intégration cartographique elle-même, déjà détaillée via Leaflet dans un autre article : il traite spécifiquement du chargement conditionnel, un problème générique qui se pose pour n’importe quel bloc dépendant d’un script tiers coûteux ou sensible.

Le problème du chargement global

La pratique la plus répandue, et la plus paresseuse, consiste à enregistrer le script et la clé API dans un hook générique comme wp_enqueue_scripts, sans condition. Le navigateur charge alors systématiquement la bibliothèque tierce, initie une connexion au service, et dans certains cas (notamment pour la géolocalisation ou le style de carte) déclenche un appel réseau consommant un crédit d’utilisation, même sur une page qui n’affiche jamais la carte.

has_block pour détecter la présence réelle

La fonction has_block() vérifie si un bloc donné est présent dans le contenu de la page actuellement affichée, sans avoir à parser le contenu manuellement :

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_singular() || ! has_block( 'ferrand/carte-agences' ) ) {
        return;
    }

    wp_enqueue_script(
        'ferrand-carte-fournisseur',
        'https://cdn.fournisseur-cartes.example/v2/script.js',
        [],
        '2.4.0',
        true
    );

    wp_localize_script( 'ferrand-carte-fournisseur', 'ferrandCarteConfig', [
        'cleApi' => get_option( 'ferrand_cle_api_carte' ),
    ] );
} );
L'essentiel à retenir : has_block évite d'injecter un script sur les pages sans carte ; La clé passée en wp_localize_script reste visible côté client ; Restreindre la clé par référent depuis la console du fournisseur

Avec cette condition, le script et la clé ne sont injectés que sur les pages qui contiennent réellement le bloc. Pour un contenu affiché via un bloc réutilisable ou dans un gabarit d’éditeur de site (où has_block seul peut ne pas suffire), la vérification doit s’étendre au contenu du gabarit avec has_block( 'ferrand/carte-agences', $wp_query->queried_object ) ou une inspection du contenu final assemblé.

La clé reste visible : ce que le chargement conditionnel ne résout pas

Un point important à clarifier auprès du client : réserver le chargement du script aux pages concernées réduit la consommation de crédit d’utilisation et la surface d’exposition, mais n’importe qui inspectant le code source de la page où le bloc est bien présent verra la clé API en clair dans wp_localize_script. Ce n’est pas un défaut du chargement conditionnel, c’est une limite inhérente à toute clé destinée à un script exécuté côté navigateur.

  • Restreindre la clé par domaine référent (« HTTP referrer ») depuis la console d’administration du fournisseur de service, une protection bien plus efficace que la dissimulation.
  • Ne jamais utiliser la même clé pour un usage serveur (facturation plus élevée, permissions plus larges) et pour cet usage client restreint.
  • Documenter dans le tableau de bord du client que cette clé est volontairement publique et protégée par restriction de domaine, pour éviter une fausse alerte de sécurité lors d’un audit ultérieur.

Vérifier l’effet réel du changement

Après la mise en place du chargement conditionnel, l’onglet réseau des outils de développement du navigateur confirme qu’aucune requête vers le domaine du fournisseur n’est initiée sur les pages sans le bloc carte, contre une requête systématique auparavant sur toutes les pages du site.

Un script tiers facturé à l’usage ne devrait jamais être chargé par défaut : il devrait être l’exception, conditionnée à la présence réelle de ce qui le justifie.

En résumé

Le chargement conditionnel via has_block() a ramené la consommation de crédits du service cartographique du Cabinet Ferrand à exactement la page qui en a besoin, sans toucher à l’intégration elle-même. Le principe se généralise à tout bloc dépendant d’un script tiers : la question à se poser n’est pas « comment charger ce script », mais « sur quelles pages ce script a-t-il une raison d’être présent ».

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi