POST https://api.sendinblue.com/v3/contacts — une seule requête HTTP suffit, en théorie, à ajouter un contact dans une liste Sendinblue. C’est ce point de départ qui a guidé l’intégration d’un formulaire de capture d’e-mail directement dans un template part du Site Editor, sans passer par une extension newsletter dédiée, sur un premier site construit avec le plugin Gutenberg en mode expérimental.
Le client, une petite marque de cosmétique artisanale, ne voulait pas multiplier les extensions sur son site : chaque plugin supplémentaire représentait, à ses yeux, un risque de conflit et une ligne de maintenance en plus. L’éditeur de site, encore jeune à cette date, offrait une occasion de tester une approche plus légère : un simple template part réutilisable, contenant le formulaire, appelé sur toutes les pages via le bloc Template Part.
Pourquoi un template part plutôt qu’un widget classique
Sur un thème bloc, un template part se comporte comme un widget réutilisable, mais avec l’avantage d’être modifiable visuellement depuis le Site Editor, sans passer par l’éditeur de widgets classique encore utilisé sur les thèmes non compatibles blocs. Le formulaire de capture d’e-mail a donc été construit comme un template part indépendant, inséré en pied de page sur l’ensemble du site via le bloc core/template-part.
Cette approche permet à l’équipe éditoriale de modifier le texte d’accroche du formulaire directement depuis l’éditeur de site, sans intervention d’un développeur, tout en gardant le comportement technique du formulaire strictement contrôlé par le code.
Étape 1 : créer une clé API Sendinblue restreinte
Première étape, indépendante du Site Editor : générer, depuis le tableau de bord Sendinblue, une clé API dédiée à ce formulaire, avec les permissions les plus restreintes possibles. Exposer une clé API complète côté client serait une faute grave de sécurité ; la bonne pratique consiste à passer par une route intermédiaire côté serveur.
Étape 2 : créer une route REST WordPress intermédiaire
Le navigateur du visiteur n’appelle jamais directement l’API Sendinblue : il envoie l’e-mail saisi à une route REST personnalisée, déclarée dans le thème, qui se charge elle-même de l’appel vers Sendinblue avec la clé API stockée côté serveur, jamais exposée au client.
add_action( 'rest_api_init', function () {
register_rest_route( 'wpm/v1', '/newsletter', array(
'methods' => 'POST',
'callback' => 'wpm_inscrire_contact_sendinblue',
'permission_callback' => '__return_true',
) );
} );
function wpm_inscrire_contact_sendinblue( $request ) {
$email = sanitize_email( $request->get_param( 'email' ) );
if ( ! is_email( $email ) ) {
return new WP_Error( 'email_invalide', 'Adresse invalide', array( 'status' => 400 ) );
}
$reponse = wp_remote_post( 'https://api.sendinblue.com/v3/contacts', array(
'headers' => array(
'api-key' => SENDINBLUE_CLE_API,
'Content-Type' => 'application/json',
),
'body' => wp_json_encode( array( 'email' => $email, 'listIds' => array( 4 ) ) ),
) );
return array( 'ok' => ! is_wp_error( $reponse ) );
}
Étape 3 : construire le formulaire dans le template part
Dans le Site Editor, le template part contient un bloc HTML personnalisé minimal : un champ e-mail, un bouton, et un script inline qui intercepte la soumission pour appeler la route REST plutôt que de recharger la page.
- Insérer un template part dédié via le bloc Template Part du Site Editor.
- Ajouter un bloc HTML personnalisé contenant le formulaire minimal.
- Enregistrer un script séparé, via
wp_enqueue_script(), plutôt que du JavaScript collé dans le bloc, encore instable à l’enregistrement à cette date. - Tester la soumission et vérifier l’apparition du contact dans Sendinblue.
Étape 4 : afficher un message de confirmation sans rechargement
Le script intercepte la réponse de la route REST et remplace le contenu du formulaire par un message de confirmation, sans recharger la page ni rediriger le visiteur, pour garder l’expérience fluide sur ce petit site vitrine.
Ce que cette intégration ne couvre pas
Ce billet ne traite pas des scénarios d’automatisation Sendinblue (séquences d’e-mails déclenchées, segmentation avancée des contacts), qui relèvent d’une configuration propre à l’outil, indépendante du site WordPress. Il ne couvre pas non plus le suivi des ouvertures ou des clics, qui nécessiterait une intégration plus poussée avec les webhooks de Sendinblue.
Un formulaire de capture d’e-mail n’a pas besoin d’une extension dédiée dès qu’il reste simple : une route REST maison et quelques lignes de JavaScript suffisent, et le client garde un site plus léger à maintenir sur la durée.
En résumé
Appeler l’API Sendinblue depuis un template part du Site Editor évite d’installer une extension newsletter supplémentaire, à condition de passer systématiquement par une route REST intermédiaire pour ne jamais exposer la clé API côté client. Sur un site vitrine à faible trafic, cette approche reste largement suffisante, et l’équipe éditoriale garde la main sur le texte du formulaire directement depuis l’éditeur de site.
