Coller le code d’intégration fourni par une plateforme d’e-mailing revient presque toujours à embarquer une iframe ou un script tiers qui impose sa propre mise en forme, difficile à faire coïncider avec la charte graphique du site. Pour un simple champ e-mail et un bouton, cette lourdeur ne se justifie pas : un appel direct à l’API Sendinblue depuis un bloc dynamique fait le même travail, en beaucoup plus léger.
Le principe reste simple : un formulaire HTML natif, stylé avec le reste du thème, qui transmet l’adresse e-mail à une route REST WordPress, laquelle appelle l’API Sendinblue côté serveur. Aucun script Sendinblue ne se charge côté navigateur.
Pourquoi éviter le widget d’intégration fourni
Le code d’intégration standard proposé dans l’interface Sendinblue génère un formulaire dans une iframe, avec ses propres styles CSS difficiles à surcharger proprement, et un script de chargement supplémentaire. Sur un site qui soigne ses performances, ce poids et cette rigidité visuelle pèsent plus que le gain de temps sur l’intégration initiale.
Un appel API direct depuis le serveur évite aussi d’exposer la clé API dans le navigateur, ce qui serait le cas avec une intégration purement JavaScript côté client.
Construire le bloc et son formulaire
Le bloc est entièrement statique côté rendu (pas de render_callback nécessaire) : seul le comportement de soumission change, géré en JavaScript côté front.
<form class="wpm-form-sendinblue" data-liste-id="12">
<label for="email-sendinblue">Votre adresse e-mail</label>
<input type="email" id="email-sendinblue" name="email" required />
<button type="submit">S'inscrire</button>
</form>
La route REST côté serveur
La route REST reçoit l’adresse e-mail, la valide, puis appelle l’endpoint /v3/contacts de l’API Sendinblue avec la clé API stockée en constante PHP, jamais dans le dépôt de code :
define( 'SENDINBLUE_API_KEY', 'xkeysib-...' );
add_action( 'rest_api_init', function () {
register_rest_route( 'wpmoderne/v1', '/inscription-sendinblue', array(
'methods' => 'POST',
'callback' => 'wpmoderne_inscrire_contact_sendinblue',
'permission_callback' => '__return_true',
) );
} );
function wpmoderne_inscrire_contact_sendinblue( WP_REST_Request $request ) {
$email = sanitize_email( $request->get_param( 'email' ) );
if ( ! is_email( $email ) ) {
return new WP_Error( 'email_invalide', 'Adresse e-mail invalide.', array( 'status' => 400 ) );
}
$reponse = wp_remote_post( 'https://api.sendinblue.com/v3/contacts', array(
'headers' => array(
'api-key' => SENDINBLUE_API_KEY,
'Content-Type' => 'application/json',
),
'body' => wp_json_encode( array(
'email' => $email,
'listIds' => array( absint( $request->get_param( 'liste' ) ) ),
'updateEnabled' => true,
) ),
) );
if ( is_wp_error( $reponse ) ) {
return new WP_Error( 'sendinblue_indisponible', 'Service momentanément indisponible.', array( 'status' => 503 ) );
}
return array( 'succes' => true );
}
Empêcher les inscriptions automatisées
Sans protection, ce type de formulaire attire rapidement des soumissions automatisées. Un champ « pot de miel » (invisible pour un humain, rempli par les robots) reste la protection la plus simple à ajouter sans nuire à l’expérience :
- Un champ caché en CSS (jamais avec
display:nonedétecté par certains robots, plutôt positionné hors écran). - Un rejet silencieux côté serveur si ce champ est rempli, sans message d’erreur qui renseignerait le robot.
- Un
nonceWordPress classique en complément, vérifié viawp_verify_nonce()avant tout appel à l’API Sendinblue.
Confirmer l’inscription côté visiteur
Le script front remplace le formulaire par un message de confirmation une fois la requête acceptée, sans rechargement de page. En cas d’erreur réseau, le message reste actionnable : un lien « réessayer » plutôt qu’un simple texte d’échec.
Ce que cet article ne couvre pas
Les scénarios d’automatisation Sendinblue (emails de bienvenue déclenchés, séquences) se configurent entièrement côté plateforme, une fois le contact créé, et ne relèvent plus du bloc lui-même. Le suivi des ouvertures et des clics, également fourni par Sendinblue, s’active dans les réglages de campagne et ne nécessite aucun code supplémentaire côté WordPress.
En résumé
Un appel API direct depuis un bloc formulaire évite l’iframe imposée, réduit le poids de la page, et garde la main sur le design du champ d’inscription. La contrepartie est une route REST à sécuriser correctement, ce qui reste un effort raisonnable comparé au gain en cohérence visuelle et en performance.
