Modèle d'opt-in WhatsApp B2B : texte, preuve et STOP

Réponse courte

Réponse courte : un opt-in exploitable indique qui contacte la personne, pour quelle catégorie de messages et comment arrêter les communications. L’équipe doit conserver la source, la date, le texte présenté et le statut de la préférence.

Voici le modèle opérationnel : une autorisation ne devient exploitable que si l’équipe peut retrouver le contexte précis dans lequel elle a été donnée.

La décision à prendre avant de configurer quoi que ce soit

Avant d’écrire le texte, séparez l’usage de service de l’usage marketing. Un client qui demande un suivi de commande n’a pas automatiquement demandé une campagne promotionnelle. Un prospect professionnel peut relever d’un cadre différent d’un particulier, mais cette distinction ne dispense pas d’informer clairement la personne et de respecter l’opposition. La CNIL décrit les règles de prospection électronique et rappelle que l’identité de l’organisation et une voie simple de refus doivent rester compréhensibles. La politique WhatsApp Business impose de son côté l’autorisation de recontacter la personne et le respect des demandes de désinscription.

Un bon dispositif ne commence pas par le bouton d’une interface. Il commence par une décision observable : quelle donnée est autorisée, quelle action est permise, qui reprend la main, et comment l’équipe saura qu’un événement a été traité. Cette discipline évite de confondre une démonstration réussie avec une intégration exploitable en production.

1. Écrire une permission spécifique

Un bon texte nomme l’entreprise, le canal et la famille de messages. “Recevoir des informations” est trop flou si l’équipe prévoit ensuite des promotions, des rappels de rendez-vous et des relances commerciales. Le lecteur doit comprendre la scène dans laquelle son numéro sera utilisé.

Utilisez une phrase courte, puis prévoyez un lien vers la notice qui explique le traitement. Le modèle n’est jamais une autorisation universelle : si l’usage change, la base de préférence et le texte présenté doivent permettre de comprendre cette différence.

Contrôle concret

faites lire le texte à une personne qui ne connaît pas le projet et demandez-lui de reformuler qui écrira, pour quoi faire et comment arrêter.

Exemple de terrain

« J’accepte de recevoir sur WhatsApp les informations liées à [usage précis] de la part de [organisation]. Je peux arrêter ces messages à tout moment en répondant STOP. » Cet exemple doit être validé et adapté au parcours réel.

2. Distinguer service, suivi et marketing

La catégorie de message détermine la logique de collecte et le traitement des demandes d’arrêt. Un message attendu après une action du client n’est pas présenté comme une campagne ; inversement, une nouveauté ou une recommandation commerciale ne doit pas être cachée derrière une formulation de service.

Dans le CRM, stockez une préférence par catégorie plutôt qu’un seul booléen qui mélange tout. Cette granularité permet de suspendre un usage sans interrompre un suivi opérationnel que la personne attend encore.

Contrôle concret

demandez au responsable métier de compléter la phrase “nous écrirons quand…” pour chaque scénario et de faire valider la réponse par la conformité.

Exemple de terrain

Un contact peut accepter les rappels liés à un rendez-vous et refuser les actualités commerciales. Deux lignes de préférence sont plus honnêtes qu’une seule case “WhatsApp accepté”.

3. Conserver la preuve sans surcollecter

La preuve utile n’est pas une copie infinie de toute la conversation. Elle relie un contact à la source d’inscription, au moment, à la version du texte, à la catégorie acceptée et au statut courant. Les accès à cette trace doivent être limités aux personnes qui enquêtent ou opèrent le canal.

Évitez de conserver dans une note libre des informations sensibles qui n’aident pas à démontrer l’autorisation. Une structure de champs stable facilite l’audit et réduit les interprétations différentes entre équipes.

Contrôle concret

testez qu’un opérateur peut retrouver la preuve sans exporter tout l’historique du client.

Exemple de terrain

Le registre peut contenir source_formulaire, date_heure, version_consentement, categorie, preuve, statut_stop et date_retrait, avec une politique de conservation définie séparément.

4. Faire de STOP une règle de système

Une désinscription ne doit pas rester dans la mémoire d’un conseiller. Elle doit modifier la préférence qui bloque les campagnes, les scénarios automatiques et les relances déclenchées par le CRM. Si plusieurs outils écrivent la préférence, documentez la source de vérité et la synchronisation.

Répondez de manière simple à la demande d’arrêt, sans exiger une justification. Si un message est déjà en file, la règle doit préciser s’il est annulé ou s’il est seulement empêché pour les prochains envois.

Contrôle concret

envoyez un STOP de test, vérifiez chaque liste et tentez une relance ; aucune étape ne doit contourner le statut.

Exemple de terrain

Le statut “refusé” peut être prioritaire sur un statut de campagne. Un opérateur peut réactiver une catégorie seulement via un nouveau parcours explicite, jamais en éditant une fiche à la main.

5. Organiser la revue avant campagne

La dernière revue doit partir de la liste réelle de destinataires et non du seul texte. Vérifiez l’origine de chaque numéro, la catégorie de préférence, l’existence d’un STOP et la cohérence entre l’audience, le template et la finalité annoncée.

La revue doit produire une décision : autorisé, à corriger ou exclu. Enregistrez l’écart sans masquer les cas supprimés, car ces exclusions expliquent souvent pourquoi une campagne ne correspond pas au volume prévu.

Contrôle concret

faites valider un petit échantillon de contacts par une personne différente de celle qui a construit le parcours.

Exemple de terrain

Un contact importé depuis une liste ancienne peut être présent dans le CRM mais sans version du consentement. Il doit rester hors campagne jusqu’à clarification.

6. Préparer la preuve d’une demande client

La personne doit pouvoir comprendre ce qui s’est passé lorsqu’elle demande pourquoi elle a reçu un message. Préparez une réponse interne qui renvoie à la source, à la date et à la catégorie sans exposer des données d’autres personnes.

Cette préparation est aussi un test de qualité. Si l’équipe ne peut pas expliquer le parcours en quelques phrases, le registre est trop dispersé ou le texte initial était trop général.

Contrôle concret

jouez une demande “je n’ai jamais accepté” avec un contact fictif et mesurez le temps nécessaire pour retrouver la preuve.

Exemple de terrain

La réponse interne cite la page ou le formulaire d’origine, la version du texte et l’état STOP ; elle ne prétend pas que le numéro seul est une permission.

La méthode complète, étape par étape

La séquence ci-dessous est volontairement plus stricte qu’un simple tutoriel. Elle permet de prouver ce qui a été testé et de retrouver la cause d’un incident sans demander à une seule personne de se souvenir de toute l’histoire.

Étape 1 — Cartographier les usages

Listez chaque événement qui peut écrire sur WhatsApp. Pour chacun, indiquez s’il est déclenché par le client, par un processus de service ou par une action marketing. Refusez les catégories fourre-tout.

Preuve à conserver : une table des usages approuvés et des usages interdits.

Étape 2 — Rédiger et relire le texte

Écrivez une version courte, compréhensible sur mobile. Faites relire le texte par le métier et, si nécessaire, par le conseil compétent. La relecture vérifie que la promesse du texte correspond au scénario réel.

Preuve à conserver : la version datée du texte et la personne qui l’a validée.

Étape 3 — Enregistrer la source

Reliez l’autorisation au contact avec des champs structurés. Capturez le contexte minimal utile, pas une copie illimitée de données personnelles.

Preuve à conserver : un enregistrement de test dont toutes les colonnes nécessaires sont remplies.

Étape 4 — Tester l’arrêt

Envoyez des demandes STOP avec variantes de casse, espaces et formulation naturelle. Vérifiez les scénarios actifs, les segments et les files d’envoi.

Preuve à conserver : un rapport de test montrant le blocage sur chaque sortie.

Étape 5 — Approuver la campagne

Comparez audience, finalité, template et préférences. Toute différence non expliquée devient une exclusion ou un retour en correction.

Preuve à conserver : une décision signée ou attribuée, avec les exclusions conservées.

Scénarios à jouer avant de considérer le flux fiable

Un scénario de recette décrit une entrée, une décision attendue et un effet de bord autorisé. Une capture d’écran seule ne suffit pas : notez aussi l’identifiant technique, l’heure du test, la réponse HTTP ou métier, la personne qui a validé et la correction appliquée en cas d’écart.

Scénario 1 — case importé sans preuve

Entrée. un cas normal arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour case importé sans preuve, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 2 — STOP pendant une file d’envoi

Entrée. un cas incomplet ou contradictoire arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour stop pendant une file d’envoi, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 3 — préférence de service conservée

Entrée. un cas normal arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour préférence de service conservée, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 4 — changement de catégorie

Entrée. un cas incomplet ou contradictoire arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour changement de catégorie, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 5 — demande de preuve

Entrée. un cas normal arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour demande de preuve, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Scénario 6 — réactivation demandée

Entrée. un cas incomplet ou contradictoire arrive dans le flux et contient uniquement les informations que le client ou le système a réellement fournies

Attendu. le système applique la règle prévue pour réactivation demandée, sans inventer la valeur manquante et sans déclencher deux fois la même action

À vérifier. la trace permet de relier l’entrée, la décision, la sortie et le responsable de la vérification.

Tableau de contrôle réutilisable

| Point de contrôle | Question à poser | Résultat attendu | Responsable | |---|---|---|---| | Source | D’où vient le numéro ? | Source nommée et vérifiable | CRM | | Catégorie | Quel message est permis ? | Catégorie séparée | Marketing | | Version | Quel texte a été vu ? | Version datée | Conformité | | Retrait | Comment stopper ? | STOP testé | Ops | | Revue | Qui décide avant l’envoi ? | Validation attribuée | Responsable campagne |

Ce tableau doit vivre dans l’espace où l’équipe travaille réellement. Une procédure introuvable au moment d’un incident n’est pas une procédure opérationnelle. Versionnez le document, indiquez sa date de revue et rendez visible la personne qui peut l’approuver ou le corriger.

Erreurs fréquentes et corrections propres

1. Utiliser le numéro comme preuve

Un numéro identifie un contact ; il ne décrit ni le contexte, ni la catégorie, ni le texte présenté. Reliez-le à une source et à une version.

2. Mélanger service et marketing

Séparez les usages dans le modèle de données et dans les parcours. Une réponse attendue après une demande client ne doit pas servir de couverture à une campagne.

3. Gérer STOP dans une note

Faites du statut un contrôle bloquant partagé par toutes les sorties d’envoi.

4. Réutiliser un ancien formulaire

Vérifiez que le texte ancien couvre encore l’usage actuel et conservez la version réellement présentée.

Limites à expliquer honnêtement

Ce modèle ne décide pas à votre place du fondement juridique applicable à chaque population, pays ou scénario. La politique WhatsApp et les règles de protection des données peuvent évoluer. Un opt-in correct ne dispense pas de vérifier la base légale, la minimisation, la conservation et les droits des personnes.

Une automatisation peut accélérer une décision répétitive ; elle ne transforme pas une donnée périmée en vérité, une autorisation ambiguë en consentement, ni une intégration non testée en garantie de continuité. Quand l’information manque, la bonne sortie est souvent une demande de précision ou une reprise humaine, pas une réponse plus affirmative.

Questions fréquentes

FAQ

Un message entrant suffit-il à autoriser toutes les relances ?

Non. Il établit un contexte de conversation, pas une permission générale pour des catégories différentes. Décrivez la suite attendue et respectez les règles de la plateforme et du droit applicable.

Faut-il une case séparée pour WhatsApp ?

La lisibilité compte plus que le nom du composant. La personne doit pouvoir comprendre le canal et l’usage. Une case dédiée est souvent plus claire lorsque les autres canaux et finalités diffèrent.

Que faire d’un contact sans preuve ?

Mettez-le en attente, recherchez la source autorisée et ne reconstruisez pas l’accord après coup. La qualité du registre vaut mieux qu’une audience artificiellement complète.

STOP doit-il couper les messages de service ?

La réponse dépend de la catégorie et du contexte. Documentez la règle : une demande d’arrêt marketing peut ne pas annuler un message transactionnel attendu, mais elle doit être respectée pour l’usage concerné.

Peut-on réactiver un contact ?

Oui seulement via un nouveau parcours clair et traçable. Une modification manuelle ne doit pas effacer l’historique du refus.

Le modèle proposé est-il un avis juridique ?

Non. C’est un exemple rédactionnel et opérationnel à adapter et à faire valider selon le contexte.

Annexe opérationnelle — du registre d’autorisation à la revue de campagne

Cette annexe sert de feuille de travail pour une équipe qui doit prouver, avant un envoi, que chaque contact appartient au bon usage. Elle peut être copiée dans un ticket interne, mais elle ne doit pas devenir une nouvelle base parallèle : le registre CRM ou la source de vérité désignée reste l’endroit où l’état final est conservé. La personne qui relit la campagne doit pouvoir distinguer une preuve existante, une information déduite et une donnée encore manquante.

Atelier de reconstitution d’un opt-in B2B

Observation 1

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Décision 2

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Preuve 3

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Exception 4

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Reprise 5

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Revue 6

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Transmission 7

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Contradiction 8

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Traçabilité 9

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Responsabilité 10

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Limite 11

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Clôture 12

Dans ce scénario, prenez un consentement recueilli sur un formulaire ou par un échange commercial et traitez-le comme preuve d’autorisation. Avant toute automatisation, vérifiez la version du texte accepté et l’origine de la demande. Le résultat attendu n’est pas un écran rassurant : il doit permettre à le responsable de la donnée marketing de relire le choix sans interpréter les intentions de quelqu’un d’autre. Testez aussi un cas où la donnée arrive en retard ou se contredit. Le risque concret à éviter est un envoi sans fondement reconstituable. Lorsque la preuve ne suffit pas, la conduite prévue est de mettre le contact en exclusion temporaire. Conservez alors la fiche d’opt-in et le journal de préférence; cette pièce relie le test, le propriétaire et la décision qui a réellement été prise.

Pour aller plus loin sur agentic-whatsup.com

Pour le niveau supérieur, consultez Opt-in WhatsApp IA et STOP, Campagnes WhatsApp et RGPD. Ces pages n’ont pas le même rôle : l’une traite le cadre général, l’autre approfondit une intégration ou un contrôle voisin.

Si votre équipe veut vérifier le flux sur son cas réel, utilisez le contact de cadrage et décrivez le canal, la source de données, le propriétaire de la reprise et le test qui échoue. La demande porte sur le cadrage du processus ; aucun résultat de classement, de délivrabilité ou de conversion ne doit être promis avant mesure.

Sources vérifiées

Meta Business Messaging Policy · CNIL — prospection électronique · CNIL — chatbots

Les sources ci-dessus établissent les règles ou les capacités documentées. Les matrices, exemples, critères de décision et contrôles proposés dans cet article sont une méthode éditoriale adaptée au cas d’usage ; ils ne constituent pas une certification de la plateforme ni un avis juridique.