Avec la release Summer ’26 de Marketing Cloud Next, Salesforce franchit une étape attendue depuis plusieurs années : le support natif du RCS (Rich Communication Services). Concrètement, vos équipes peuvent désormais envoyer des messages enrichis – images, carrousels, boutons d’action, suggestions de réponse, marque vérifiée – directement depuis Marketing Cloud Next, sans plateforme tierce intercalaire. Pour les équipes martech françaises qui ont longtemps jonglé entre SMS Studio, MobilePush et des connecteurs externes, c’est une rupture. Cet article fait le point sur ce qui change vraiment, sur ce que cela implique côté data model, et sur la feuille de route opérationnelle à suivre pour préparer vos campagnes RCS sans casser ce qui fonctionne déjà.

RCS dans Marketing Cloud Next : de quoi parle-t-on exactement ?

RCS est le successeur officiel du SMS. Soutenu par les opérateurs et désormais supporté par iMessage côté Apple depuis iOS 18, il transforme une bulle de SMS en véritable surface conversationnelle : typing indicators, accusés de lecture, médias riches, suggested replies, et surtout verified sender avec logo de marque. Là où le SMS marketing plafonne en termes d’engagement et de différenciation, RCS rapproche le canal mobile d’une expérience type WhatsApp Business – mais dans la messagerie native du téléphone.

La nouveauté de Summer ’26 n’est pas l’existence de RCS : c’est son intégration native dans Marketing Cloud Next. Auparavant, déclencher du RCS depuis SFMC supposait un connecteur partenaire, un mapping manuel des consentements, et souvent une duplication des Data Extensions « mobile ». La release transforme RCS en canal de premier rang aux côtés d’Email, SMS et MobilePush, avec ses propres composants dans le Content Builder et son propre nœud dans Journey Builder.

Ce qui change concrètement dans la plateforme

Un nouveau canal dans Journey Builder

Le nœud RCS message apparaît dans la palette d’activités de Journey Builder, à côté du nœud SMS classique. Vous pouvez désormais router un contact vers RCS si son appareil et son opérateur le supportent, et fallback automatiquement vers SMS dans le cas contraire. Ce capability check est géré par la plateforme : vous n’avez pas à maintenir vous-même la liste des handsets compatibles.

Un Content Builder enrichi

De nouveaux types de contenu apparaissent : Rich Card, Carousel, Suggested Reply, Suggested Action (avec dial, open URL, calendar action). Ces blocs sont réutilisables comme n’importe quel Content Block, donc votre librairie existante peut être progressivement enrichie sans refonte.

Des données d’engagement spécifiques

Côté reporting, RCS expose des événements granulaires : RCS_Delivered, RCS_Read, RCS_SuggestedReplyClicked, RCS_SuggestedActionClicked. Ces événements alimentent des Data Views dédiées et sont consommables dans Data Cloud sans configuration supplémentaire dans la majorité des tenants.

L’erreur la plus fréquente en démarrage RCS : traiter le canal comme un SMS plus joli. RCS est une surface conversationnelle ; concevez vos suggested replies comme la première étape d’un dialogue, pas comme un simple call-to-action.

Le data model : ce qu’il faut ajuster côté SFMC

RCS s’appuie sur le même identifiant que le SMS : le numéro mobile. Cela simplifie la migration, mais introduit des subtilités à anticiper dans votre modèle de données.

Consentement : un statut RCS distinct

Le consentement SMS n’est pas automatiquement transférable au RCS au regard du RGPD et des recommandations CNIL. La plupart des juristes recommandent de capturer un opt-in explicite pour le canal RCS, même si l’opt-in SMS existe déjà. Prévoyez une colonne dédiée dans votre Data Extension Subscribers :

-- Data Extension "Subscribers_Mobile"
-- Champs recommandés
SubscriberKey         (Text, PK)
MobileNumber          (Phone)
SMS_OptIn             (Boolean)
SMS_OptIn_Date        (Date)
RCS_OptIn             (Boolean)
RCS_OptIn_Date        (Date)
RCS_Capable           (Boolean)   -- mis à jour par la plateforme
Locale                (Text)
LastRCSEngagement     (Date)

Requête SQL de segmentation typique

Pour cibler vos contacts éligibles à une campagne RCS prioritaire avec fallback SMS :

SELECT
  s.SubscriberKey,
  s.MobileNumber,
  CASE
    WHEN s.RCS_OptIn = 1 AND s.RCS_Capable = 1 THEN 'RCS'
    WHEN s.SMS_OptIn = 1 THEN 'SMS'
    ELSE 'SKIP'
  END AS PreferredMobileChannel
FROM Subscribers_Mobile s
WHERE s.SMS_OptIn = 1 OR s.RCS_OptIn = 1

Ce pattern simple suffit pour la majorité des cas. Pour des scénarios multi-marques ou multi-pays, ajoutez un champ BrandCode et filtrez la capability RCS par marché – RCS reste inégalement déployé selon les opérateurs.

Concevoir un premier message RCS qui convertit

RCS autorise une densité d’information bien supérieure au SMS, mais cela ne signifie pas qu’il faut tout y mettre. Trois principes émergent des premiers retours terrain :

1. Une seule intention par message

Carrousel ou Rich Card unique, vous devez pouvoir résumer le message en une phrase : « Confirmer mon rendez-vous », « Voir les 3 offres personnalisées », « Suivre ma commande ». Si la phrase est ambiguë, simplifiez.

2. Suggested replies courts et orientés action

Limitez-vous à 3 à 4 suggested replies. Évitez les libellés génériques type « OK » ou « En savoir plus ». Préférez « Réserver le créneau », « Reporter d’une semaine », « Parler à un conseiller ».

3. Brand verification activée dès le pilote

Demandez la vérification de votre RCS Business Messaging brand dès la phase pilote. Sans logo vérifié, votre message ressemble à un SMS classique et l’uplift d’engagement disparaît. Le processus de vérification prend en général 2 à 4 semaines selon les opérateurs.

Migration progressive : ne cassez pas vos journeys existants

La tentation est forte de basculer toutes vos campagnes SMS vers RCS. C’est une erreur opérationnelle. Procédez par paliers :

Palier 1. Doublez en parallèle un journey transactionnel à fort volume (confirmation de commande, code OTP) en RCS pour les contacts RCS_Capable, en gardant le SMS comme fallback. Mesurez delivery rate et delta de coût – le RCS reste plus cher que le SMS en France.

Palier 2. Activez RCS sur un journey promotionnel ciblé (drop dédié, segment VIP) avec un carrousel produit. Comparez l’engagement aux campagnes SMS équivalentes.

Palier 3. Industrialisez la décision RCS/SMS dans Journey Builder via un decision split sur PreferredMobileChannel, et formez vos équipes contenu aux composants riches.

Les pièges à éviter dans les 90 premiers jours

Trois écueils reviennent systématiquement dans les premiers déploiements : confondre RCS et OTT (Over The Top, type WhatsApp) dans la facturation, oublier le consentement explicite RCS, et négliger le fallback SMS pour les contacts non éligibles. Chacun peut être anticipé via une checklist simple validée avant le go-live, et c’est exactement le type de mission sur laquelle CGC-Agency accompagne les équipes martech. Si vous préparez votre activation RCS dans SFMC, contactez-nous pour un cadrage rapide.

À retenir

Point 1. RCS est natif dans Marketing Cloud Next Summer ’26 : un nouveau nœud dans Journey Builder, de nouveaux composants dans le Content Builder, et des Data Views dédiées.

Point 2. Le consentement SMS ne couvre pas le RCS : prévoyez un opt-in explicite et un champ RCS_OptIn distinct dans vos Data Extensions.

Point 3. Pensez RCS comme une surface conversationnelle, pas comme un SMS enrichi : les suggested replies sont la clé de l’uplift.

Point 4. Migrez par paliers en commençant par un journey transactionnel, avec SMS toujours en fallback géré côté plateforme.

Point 5. Activez la brand verification dès le pilote, sans elle vous perdez le différenciateur visuel qui justifie le coût supplémentaire.