Comment une équipe marketing multiplie-t-elle les langues d’un site sans multiplier les formulaires HubSpot à maintenir ? La question s’est posée concrètement pour une entreprise B2B présente sur un site WordPress en quatre langues (français, anglais, allemand, italien), avec un pipeline commercial distinct par zone géographique dans HubSpot, chacun affecté à une équipe commerciale différente.
La première tentation, dupliquer le formulaire de contact quatre fois, un par langue, a été écartée dès la phase de cadrage : quatre formulaires signifient quatre points de maintenance à synchroniser à chaque modification de champ, et un risque réel d’oubli qui laisse une version obsolète en production pendant des mois.
Un seul formulaire, un champ caché qui capture la langue
La solution retenue repose sur un formulaire HubSpot unique, embarqué sur les quatre versions linguistiques de la page de contact via le même shortcode ou bloc d’intégration. Un champ caché, non visible pour le visiteur, capture automatiquement la langue de la page courante grâce à la fonction Polylang pll_current_language() :
<?php
// Dans le template de la page de contact
$langue_active = pll_current_language(); // "fr", "en", "de" ou "it"
?>
<script>
hbspt.forms.create({
region: "eu1",
portalId: "XXXXXXX",
formId: "YYYYYYYY-YYYY",
onFormReady: function($form) {
$form.find('input[name="langue_site"]').val('<?php echo esc_js( $langue_active ); ?>');
}
});
</script>Ce champ caché langue_site existe dans HubSpot comme une propriété de contact dédiée, invisible dans le formulaire affiché au visiteur mais bien enregistrée à chaque soumission.
Le routage se fait dans un workflow HubSpot, pas dans WordPress
Une fois la propriété langue_site renseignée sur le contact, un workflow HubSpot classique (déclenché à la création ou à la mise à jour du contact) se charge d’assigner l’opportunité créée au bon pipeline et à la bonne équipe commerciale, selon une simple condition sur cette propriété :
- Si
langue_site= « de » → pipeline « DACH », affectation à l’équipe germanophone - Si
langue_site= « it » → pipeline « Italie », affectation à l’équipe italienne - Si
langue_site= « fr » ou « en » → pipeline « France & International », affectation par défaut
Cette logique de routage vit entièrement côté HubSpot, dans le générateur de workflows visuels, ce qui permet à l’équipe marketing de modifier les règles d’affectation sans intervention d’un développeur WordPress, une fois le champ caché en place.
Le cas des visiteurs qui changent de langue en cours de visite
Un visiteur qui commence sa navigation en anglais puis bascule en allemand avant de soumettre le formulaire pose une question simple : quelle langue doit primer ? Le choix retenu a été de capturer la langue de la page où se trouve effectivement le formulaire au moment de la soumission, pas la langue de la première page visitée. C’est un choix pragmatique plutôt qu’une vérité absolue : il suppose que la dernière langue choisie reflète mieux la préférence réelle du visiteur au moment de passer à l’action.
Pourquoi ne pas simplement créer quatre formulaires distincts
L’argument principal en faveur du formulaire unique n’est pas technique mais organisationnel : quand l’équipe marketing ajoute un champ (un menu déroulant de secteur d’activité, par exemple), elle le fait une seule fois, sur un seul formulaire, sans risque de désynchronisation entre versions linguistiques. Le compromis accepté est l’obligation de garder une structure de champs identique dans toutes les langues ; un champ spécifique à un seul marché resterait, lui, plus simple à gérer avec un formulaire séparé pour ce marché uniquement.
En résumé
Router des prospects multilingues vers plusieurs pipelines commerciaux ne nécessite pas de dupliquer le formulaire par langue : un champ caché qui capture la langue de la page, couplé à un workflow HubSpot de routage conditionnel, suffit à automatiser l’affectation tout en gardant un point unique de maintenance côté WordPress.
