Formulaires et landing pages dans Salesforce Marketing Cloud Next

Pendant plus de dix ans, chaque formulaire d’inscription, chaque landing page et chaque centre de préférences construit dans Salesforce Marketing Cloud est passé par CloudPages, AMPscript et une bonne dose de code maison. La release Summer ’26 de Marketing Cloud Next change la donne : les formulaires, les pages d’atterrissage et les pages de préférences deviennent des objets natifs de la plateforme, personnalisables sans écrire une ligne de SSJS. Voici comment reconstruire votre acquisition et votre gestion de consentement sur ces nouvelles briques, ce que vous gagnez, et ce qu’il faut malgré tout conserver dans Engagement.

Ce que Summer ’26 change concrètement

Trois évolutions comptent vraiment pour les équipes qui opèrent SFMC au quotidien.

Les formulaires deviennent des composants de campagne

Auparavant, monter une campagne d’acquisition dans Marketing Cloud Next imposait de choisir le flow « Signup Form » puis de configurer chaque étape à la main : page, champs, mapping, confirmation. Les modèles de flow font désormais ce travail pour vous. Vous partez d’un template, vous ajustez les champs, et le mapping vers vos Marketing Objects est déjà câblé.

Les landing pages acceptent le contenu dynamique préconfiguré

Les templates de landing page supportent des règles de contenu dynamique et des champs de fusion multi-objets. Une même variation peut être synchronisée sur plusieurs composants de la page : le bandeau, l’accroche et le formulaire réagissent ensemble au même critère de segmentation, au lieu de diverger au fil des modifications.

Les polices personnalisées arrivent dans Content Builder

Vous pouvez charger vos web fonts de marque et les utiliser dans les e-mails, les landing pages, les formulaires et les templates, avec des polices de repli définies par business unit. Fin des titres exportés en image pour respecter la charte graphique.

Étape 1 — Créer un formulaire natif

Partez du modèle de flow d’acquisition plutôt que d’une page vierge. La logique de mapping se déclare au niveau du formulaire, pas dans le code de la page. Un formulaire de collecte de leads correctement configuré écrit directement dans un Marketing Object :

{
  "formName": "Newsletter_FR_2026",
  "targetObject": "Contact__mo",
  "fields": [
    { "name": "email",      "mapTo": "Email__c",         "required": true },
    { "name": "firstName",  "mapTo": "FirstName__c",     "required": false },
    { "name": "segment",    "mapTo": "Interest__c",      "type": "picklist" },
    { "name": "optInEmail", "mapTo": "Consent_Email__c", "type": "boolean" }
  ],
  "consentModel": "explicit",
  "onSubmit": { "action": "triggerFlow", "flowId": "welcome_fr_v2" }
}

Point d’attention : déclarez le consentement comme un champ de formulaire à part entière, pas comme une case cochée par défaut dans le template. C’est ce champ qui alimente le mapping de consentement vers Engagement, et c’est lui que la CNIL vous demandera de tracer en cas de contrôle.

Étape 2 — Personnaliser la page avec Handlebars

Les landing pages de Marketing Cloud Next utilisent Handlebars, pas AMPscript. La bascule mentale est réelle : on ne manipule plus des variables impératives, on décrit un rendu à partir d’un contexte de données. Un bloc de personnalisation typique :

<section class="hero">
  {{#if contact.FirstName__c}}
    <h2>Bonjour {{contact.FirstName__c}}, votre sélection est prête</h2>
  {{else}}
    <h2>Votre sélection personnalisée vous attend</h2>
  {{/if}}

  {{#each recommendations as |item|}}
    <article>
      <h3>{{item.title}}</h3>
      <p>{{formatCurrency item.price "EUR" locale="fr-FR"}}</p>
    </article>
  {{/each}}
</section>

À comparer avec l’équivalent AMPscript que vos équipes maintiennent probablement encore sur une CloudPage :

%%[
  SET @first = AttributeValue("FirstName")
  IF NOT EMPTY(@first) THEN
    SET @headline = Concat("Bonjour ", @first, ", votre sélection est prête")
  ELSE
    SET @headline = "Votre sélection personnalisée vous attend"
  ENDIF
]%%
<h2>%%=v(@headline)=%%</h2>

Le code Handlebars est plus court, mais surtout il est déclaratif et testable : le même template rendu avec un contexte JSON de test produit un résultat vérifiable, ce qui ouvre enfin la porte à de vrais tests de non-régression sur vos pages.

Étape 3 — Le centre de préférences sans CloudPages

C’est le gain le plus tangible. Depuis Spring ’26, la page de préférences personnalisée est un objet natif ; Summer ’26 y ajoute le mapping de consentement SMS et WhatsApp, déployé progressivement jusqu’au 17 août 2026.

Le schéma de préférences se déclare une fois et sert à la fois la page et les décisions de ciblage :

{
  "preferenceCenter": "prefs_fr",
  "channels": [
    { "key": "email_promo", "label": "Offres et promotions", "default": false },
    { "key": "email_news",  "label": "Actualités produit",   "default": false },
    { "key": "sms",         "label": "SMS transactionnels",  "default": false },
    { "key": "whatsapp",    "label": "WhatsApp",             "default": false }
  ],
  "globalOptOut": { "key": "unsubscribe_all", "honorsChannelLevel": true },
  "auditTrail": true
}

Deux règles à ne pas négocier. Premièrement, activez l’audit trail : sans horodatage de chaque changement de préférence, votre preuve de consentement ne vaut rien. Deuxièmement, vérifiez que globalOptOut respecte bien la granularité par canal ; un désabonnement global qui écrase silencieusement les consentements SMS est un incident de conformité, pas un détail d’implémentation.

La vraie économie n’est pas le temps de développement initial d’une landing page : c’est la dette de maintenance. Chaque CloudPage AMPscript que vous ne créez pas en 2026 est un actif que personne n’aura à déboguer en 2029, quand son auteur aura quitté l’entreprise.

Étape 4 — Ce qui reste dans Engagement

Ne déclarez pas la victoire trop vite. Plusieurs cas d’usage justifient encore CloudPages et AMPscript :

Les pages qui interrogent une Data Extension en lecture directe via SSJS
Les intégrations qui reçoivent un POST externe et le traitent côté serveur
Les pages de désabonnement historiques référencées dans des e-mails déjà envoyés
Les microsites multi-pages avec routage conditionnel complexe

Le bon arbitrage : tout ce qui est formulaire de collecte ou gestion de préférences part vers Next. Tout ce qui est logique applicative reste, pour l’instant, dans Engagement.

Un plan de migration en quatre semaines

Semaine 1 : inventoriez vos CloudPages actives et classez-les en trois catégories (formulaire, préférence, applicatif). Semaine 2 : rebâtissez en natif votre formulaire d’inscription le plus fréquenté et faites tourner les deux versions en parallèle. Semaine 3 : migrez le centre de préférences en conservant l’ancienne URL en redirection 301. Semaine 4 : comparez le taux de complétion et le temps de chargement des deux versions avant d’arbitrer la bascule complète.

À retenir

Les formulaires sont natifs. Partez d’un modèle de flow d’acquisition, pas d’une page vierge, car le mapping vers vos Marketing Objects est déjà câblé.

Handlebars remplace AMPscript sur les pages. Le template devient déclaratif et testable avec un contexte JSON, ce qui rend possibles de vrais tests de non-régression.

Le centre de préférences est le chantier prioritaire. C’est là que la dette AMPscript est la plus lourde et le risque de conformité le plus élevé.

Activez l’audit trail dès le premier jour. Un consentement sans horodatage n’est pas une preuve opposable en cas de contrôle CNIL.

CloudPages ne disparaît pas. Gardez-y la logique applicative et les intégrations serveur, et migrez uniquement la collecte et les préférences.

Vous préparez la migration de vos CloudPages vers Marketing Cloud Next et vous voulez sécuriser le volet consentement ? Parlons de votre contexte SFMC.