Modèles

Un modèle, c'est le texte d'un message avec des trous numérotés, remplis au moment de l'envoi : le prénom du client, son numéro de commande, le montant à payer. Tout ce que Trackily envoie sur WhatsApp part d'un modèle — jamais d'un texte tapé à la volée.

Concept

Un modèle appartient à un compte. Il en existe deux sortes, qui se manipulent ensuite exactement de la même façon dans les séquences, le journal et les réglages :

Deux règles valent pour les deux :

1. Seul un modèle approuvé part. Un modèle en attente, refusé, en pause, désactivé ou au statut inconnu ne part pas : l'envoi est sauté, avec la raison au journal.
2. La catégorie décide des gardes. Un modèle UTILITY ou AUTHENTICATION passe sans consentement marketing et malgré une désinscription « marketing seulement ». Tout le reste — y compris une catégorie absente ou inconnue — est traité comme MARKETING : consentement exigé (si la liste l'exige), suppression marketing respectée, pause de 24 h après un refus de l'écosystème. Dans le doute, la garde s'applique.

Les envois hors séquence — confirmation COD, message après achat, envoi d'essai — exigent un modèle UTILITY : ce chemin ne sert pas à contourner le consentement marketing.

Les modèles du fournisseur

Synchroniser

Comptes → Modèles → Synchroniser depuis le fournisseur. Trackily lit le catalogue du compte chez le fournisseur : nom, langue, catégorie, statut, variables, raison d'un refus. Le compte rendu dit combien de modèles ont été lus, approuvés, en attente et refusés.

• Si la synchronisation échoue, rien n'est écrit : l'ancien état reste.
• Un modèle qui a disparu chez le fournisseur passe en « désactivé » : ses envois s'arrêtent au lieu d'échouer un par un chez le fournisseur.
• Le filtre de la boîte montre les modèles par statut : Approuvés, En attente, Refusés, En pause, Désactivés, Inconnus.

Les statuts suivent aussi le fournisseur en continu : chez Meta, un changement de statut d'un modèle arrive par le webhook et s'applique tout de suite. Et quand le fournisseur refuse un envoi parce que le modèle a changé chez lui, l'envoi est sauté et Trackily relance une synchronisation du compte en arrière-plan.

Les variables

Les trous d'un modèle deviennent des clés qu'une étape (ou un réglage) doit remplir :

Une réponse rapide n'a pas de variable. La boîte des modèles et les formulaires d'étape rappellent les clés attendues (« Variables attendues : … »).

Les modèles locaux (cartes SIM)

Un compte WhatsApp Web n'a pas de catalogue chez un fournisseur : Synchroniser n'existe pas pour lui, le bouton Modèles locaux prend sa place. Les modèles s'écrivent là, et partent tels quels, sans approbation : c'est vous qui répondez de leur contenu.

Comptes → Modèles → Modèles locaux → Nouveau modèle local.

Les variables se déduisent du texte :

• elles s'écrivent {{1}}, {{2}}… et rien d'autre : {{prenom}} ou {{ 1 }} sont refusés, parce qu'ils partiraient tels quels chez le client ;
• elles se numérotent sans trou : un texte qui a {{1}} et {{3}} sans {{2}} est refusé, l'étape ne saurait pas quoi mettre ;
• un même numéro peut revenir plusieurs fois dans le texte ; 100 variables au plus.

Un exemple qui tient la route :

Bonjour {{1}}, votre commande {{2}} est bien enregistrée.
Montant à régler à la livraison : {{3}}.
Répondez STOP pour ne plus recevoir de messages.

Le prénom pour que ce ne soit pas un message de masse, l'information utile d'abord, et la sortie rappelée en clair : un client qui sait comment partir vous signale moins.

Un modèle local ne porte pas de boutons. Il ne peut donc pas servir à la confirmation COD, qui exige deux boutons de réponse rapide.

Un modèle UTILITY ne vend pas

La catégorie UTILITY dispense le message du consentement marketing, de la désinscription « marketing » et de la pause de l'écosystème. Trackily lit donc le texte d'un modèle UTILITY au moment où vous l'enregistrez, et le refuse s'il ressemble à une promotion :

• un seul indice fort suffit : une remise chiffrée (« -20 % », « 30 % off », « 30 % sur votre prochaine commande », « -50 DH sur votre prochaine commande », « profitez de -50 DH », « 10 € offerts sur votre prochaine commande », « 10 € offerts dès 50 € d'achat », « 50 MAD de réduction », « Remise exceptionnelle de 100 DH », « $10 off », « خصم ٣٠٪ », « خصم 50 درهما »), un code promo (« code promo », « avec le code BIENVENUE », « use code WELCOME10 », « كود خصمك », « 20 % sur votre commande avec le code SUMMER20 », y compris à côté de « paiement à la livraison » ou d'une promesse de livraison comme « votre commande sera livrée en 24h »), des soldes (Black Friday, ventes flash…), un prix barré (« 399 », « au lieu de 399, seulement 299 », « 999 MAD au lieu de 1.299 MAD », « 299 درهم بدلا من 399 درهم », « 49 درهما بدلا من 99 درهما », « السعر 299 عوض 399 »), un appel à acheter (« achetez », « ne ratez pas », « dernière chance », « اشتري الآن » — sauf devant un geste utilitaire : « dernière chance de confirmer votre commande » passe) ;
• sinon, il en faut deux plus faibles et de natures différentes : une offre, un cadeau ou « gratuit », une nouveauté, une urgence (« ce week-end », « aujourd'hui seulement », « ne manquez pas »), un lien vers la boutique (/collections/, /products/…).

Ce qui passe sans rien demander : un suivi de colis (« code de suivi », lien de suivi, « pour suivre votre colis, utilisez le code CE123456789MA »), « livraison gratuite » ou « livraison offerte » (c'est un fait de la commande, même avec son montant : « frais de livraison de 30 MAD offerts », « Livraison : 30 MAD offerts »), « paiement à la livraison » ou « الدفع عند الاستلام », un code de confirmation ou de retrait (« avec le code 4821 pour retirer votre colis », « le code reçu par SMS », « au point relais avec le code AB12CD », « retrait en magasin : utilisez le code RETRAIT24 »), la référence d'une commande (« votre commande avec le code CMD1234 est en préparation »), un mot qu'on répond (« répondez avec le code STOP », « répondez avec le code CONFIRMER »), un récapitulatif de commande (« 2 x Crème - 398 MAD », « Acompte : -50 MAD »), « la remise de votre colis », un report de livraison, en français, en anglais ou en arabe (« le livreur passera à 14h au lieu de 10h », « delivered on 15 October instead of 12 October », « livré le 15 au lieu de 12, total 299 MAD », « سيصلك الطلب يوم 15 بدلا من 12 », « غادي يوصلك الليفرور مع 14 عوض 10 »), une quantité (« 2 paiements au lieu de 1 », « توصلي بجوج ديال القطع بدل 3 »), « quand vous achetez 2 articles, la livraison est groupée », « si vous en achetez deux », une relance (« ne tardez pas à confirmer votre commande », « dernière chance de confirmer votre commande », « آخر فرصة لتأكيد طلبك »), « Votre offre est confirmée. Paiement à la livraison gratuite ». Le contenu des variables ({{1}}…) n'est jamais lu : un produit nommé « Pack Promo -30 % » ne fait refuser aucun message.

Avant la relecture de cette vérification, un report de livraison, une relance de confirmation ou « ne manquez pas le livreur » étaient refusés comme des promotions, alors que « 30 % sur votre prochaine commande avec le code BIENVENUE », « -50 DH sur votre prochaine commande » ou « كود خصمك » passaient sans rien demander. Une seconde passe a retiré ensuite les refus que la première avait créés : jusque-là, « pour suivre votre colis, utilisez le code CE123456789MA », « répondez avec le code STOP », le tiret d'un récapitulatif (« Crème - 398 MAD »), « Livraison : 30 MAD offerts » et une date (« 15 October instead of 12 October ») étaient refusés, et « 999 MAD au lieu de 1.299 MAD » passait. Une troisième passe a refermé ce que la seconde avait ouvert, et ce qui restait avant elle : jusque-là, « Suivez-nous sur Instagram, utilisez le code INSTA10 », « Nouvelle collection : utilisez le code SUMMER24 » ou « Utilisez le code BIENVENUE10, paiement à la livraison » passaient sans rien demander, tandis qu'un report de livraison en arabe (« سيصلك الطلب يوم 15 بدلا من 12 »), « votre commande avec le code CMD1234 est en préparation », « répondez avec le code CONFIRMER » et « si vous en achetez deux, la livraison est groupée » étaient refusés. Toutes ces phrases, et celles qu'aucune passe n'avait réglées, forment depuis un corpus unique que chaque retouche du détecteur doit tenir entier : avant lui, « dernière chance de confirmer votre commande » était encore refusée, et « 49 درهما بدلا من 99 درهما », « Remise exceptionnelle de 100 DH » ou « 20 % sur votre commande avec le code SUMMER20 » passaient. Ce qui reste ambigu (un montant seul comme « -50 DH », « 299 au lieu de 399 » sans devise, « use code welcome » en minuscules) n'est pas refusé ; à l'inverse, quelques messages qui empruntent la forme d'une promotion le restent (« vous avez payé 299 MAD au lieu de 249 MAD ») : la case de confirmation est là pour eux.

Le refus s'affiche en entier dans le formulaire, qui reste ouvert. Il cite les passages en cause, dit combien de messages déjà en file partiraient avec ce texte, et ce que vous pouvez faire :

• passer le modèle en MARKETING — sauf s'il sert la confirmation COD, le message après achat ou une liste Commandes : ces envois exigent un UTILITY. Écrivez alors la promotion dans un modèle MARKETING à part (Trackily refuse d'ailleurs de faire quitter UTILITY au modèle choisi dans les réglages, et à celui qu'attendent encore des confirmations de commande, des messages après achat ou des envois d'essai déjà en file : choisir un autre modèle dans les réglages ne change pas celui des envois déjà programmés — attendez qu'ils partent, ou annulez-les depuis le journal des envois) ;
• retirer ces passages ;
• ou, si le message ne vend vraiment rien, cocher « Je confirme que ce message n’est pas promotionnel » et enregistrer à nouveau. La case ne vaut que pour ce texte-là : si vous le modifiez, elle ne compte plus et Trackily redemande. Rien n'est retenu d'une fois sur l'autre.

Quand vous passez un modèle en UTILITY, ou changez le texte d'un modèle UTILITY, Trackily relit aussi les valeurs fixes de ses étapes — même en pause — et celles des messages de séquence déjà en file : « Bonjour {{1}} » est un texte propre, mais plus quand une étape met « -20 % avec le code PROMO20 » dans {{1}}. Le refus nomme les étapes en cause (« séquence / étape ») : corrigez leurs paramètres, ou confirmez. Avant le 26 septembre 2026, seul le texte était relu à cet instant, et une telle étape partait en UTILITY sans rien demander.

Renommer un modèle, changer sa langue ou le réenregistrer sans toucher au texte ne redemande rien. Un modèle UTILITY écrit avant cette vérification n'est pas bloqué : la liste des modèles locaux le signale par une pastille « contenu promotionnel ? » suivie des passages en cause. Corrigez-le, ou passez-le en MARKETING : tant qu'il reste tel quel, il part sans les protections marketing.

L'assistant (agent MCP) rencontre le même refus. Il doit vous montrer les passages en cause et ne peut confirmer qu'avec votre accord : il obtient d'abord un aperçu, puis un jeton de confirmation à renvoyer.

C'est un garde-fou contre l'erreur de bonne foi, pas un filtre infaillible : une promotion tournée autrement, ou écrite en darija en lettres latines, peut passer. La catégorie reste votre responsabilité.

Un modèle local et un groupe de SIM

Un modèle local appartient à la SIM qui l'a créé, mais toute SIM du même groupe peut l'envoyer : c'est le même texte, sans catalogue à approuver, et c'est ce qui rend la rotation possible. Il faut que la SIM propriétaire du modèle soit elle-même rangée dans ce groupe. C'est aussi ce que le routage vérifie avant de retenir un groupe pour un envoi : un groupe qui a des SIM, mais dont aucune ne porte le modèle, n'est pas retenu, et l'écart est écrit dans la page Logs (groupe_sans_le_modele). Cette souplesse n'existe pas pour l'API officielle, où un modèle est approuvé numéro par numéro.

Ranger ailleurs la SIM qui porte un modèle peut donc laisser des listes sans SIM capable de le dire : ce rangement est refusé quand il laisserait une liste d'un autre métier sur ce modèle, ou le modèle de la confirmation COD ou du message après achat dans un groupe Marketing (voir Rotation).

Retoucher un texte déjà utilisé

Changer le texte change ses variables. Trackily vérifie donc, avant d'écrire :

• que chaque étape qui utilise le modèle — y compris une étape désactivée qui a encore des messages en file — remplit toutes les nouvelles variables. Sinon, la modification est refusée et le message nomme les étapes à compléter ;
• que les messages déjà en file sans étape (confirmation de commande, message après achat, envoi d'essai) portent de quoi remplir le nouveau texte. Sinon, refus : annulez-les depuis le journal, ou gardez le texte actuel.

Les messages en file programmés par une étape sont réalignés sur les paramètres de leur étape, et la réponse dit combien.

Supprimer un modèle local

La suppression est immédiate et définitive. Dans le même geste :

• les messages encore en file qui l'utilisent sont annulés ;
• les étapes qui l'utilisaient sont détachées et désactivées — elles n'enverront plus rien tant qu'un autre modèle ne leur est pas donné ;
• les messages déjà remis à la passerelle ne sont pas rappelables : ils sont comptés à part.

La confirmation affiche d'abord combien d'étapes utilisent le modèle, et la réponse dit ce qui a été détaché et annulé.

Remplir les variables

Une étape de séquence (et les réglages du message après achat et de la confirmation COD) remplit chaque clé avec un texte, qui peut contenir les variables de Trackily :

{ "body.1": "{{first_name}}", "body.2": "{{order_number}}", "body.3": "{{order_total}}" }

Le tableau HTML de commande ({{order_table}}) n'existe pas ici : un message WhatsApp est du texte. Sur l'API officielle (Meta, 360dialog, Twilio), les sauts de ligne d'une valeur (la liste des articles, par exemple) sont remplacés par « · », parce qu'une variable de modèle multiligne y est refusée. Un modèle local, lui, garde ses sauts de ligne.

Une variable qui se rend vide fait échouer l'envoi. Un abonné sans nom pour {{first_name}}, un envoi sans commande pour {{order_number}} : l'envoi échoue en parametre_manquant plutôt que de partir avec un trou. Choisissez des variables que vos abonnés ont vraiment.

Quand le modèle d'une étape est UTILITY (quel que soit le fournisseur), Trackily lit aussi ses valeurs fixes — ce que vous tapez dans les paramètres, hors variables {{…}}. Une étape « Bonjour {{1}} » dont body.1 vaut « -20 % avec le code PROMO20 » est refusée comme le serait le texte, avec la même case de confirmation dans la boîte de l'étape. Changer un délai, un nom ou mettre l'étape en pause ne redemande rien. Les paramètres du message après achat et de la confirmation COD, eux, ne sont pas vérifiés : n'y mettez rien qui se vende.

Une étape ne s'enregistre pas si ses paramètres ne couvrent pas toutes les clés du modèle : le refus vient à l'enregistrement plutôt que six heures plus tard sur chaque abonné. Les paramètres de la confirmation COD suivent la même règle, et n'acceptent en plus que les variables d'une commande (ni {{custom.X}}, ni {{enrolled_date}} : la demande part sans abonné). Le message après achat, lui, n'est vérifié qu'à l'envoi.

Erreurs courantes

• « Seuls les modèles approuvés partent » — le modèle est en attente, refusé ou en pause chez le fournisseur. Corrigez-le chez lui, puis resynchronisez.
• modele_non_approuve au journal alors que le modèle est approuvé — il appartient à un autre compte que celui qui envoie (et, sur les SIM, à une SIM hors du groupe). Choisissez un modèle du compte de la liste.
• « Marqueur invalide » sur un modèle local — une variable nommée ou espacée. Utilisez {{1}}, {{2}}…
• « Les variables du texte sautent un numéro » — renumérotez de 1 à N sans trou.
• Le texte est accepté puis refusé en ajoutant un emoji — la limite compte un emoji pour deux caractères.
• « … ressemble à une promotion » — un modèle ou une étape UTILITY dont le texte vend. Passez en MARKETING, retirez les passages cités, ou cochez « Je confirme que ce message n’est pas promotionnel » si ce n'est pas le cas.
• « … ces envois exigent un modèle UTILITY » — vous passez en MARKETING le modèle de la confirmation COD ou du message après achat. Créez un modèle MARKETING à part, ou choisissez d'abord un autre modèle dans les réglages WhatsApp, puis attendez que les envois déjà en file sur celui-ci soient partis.
• « … est attendu par N envoi(s) déjà en file sans abonné » — des confirmations de commande, des messages après achat ou des envois d'essai déjà programmés partiront avec ce modèle : en MARKETING, ils seraient sautés (pas d'abonné, donc pas de consentement). Attendez qu'ils partent, annulez-les depuis le journal des envois, ou créez un modèle MARKETING à part.
• Synchroniser renvoie une erreur sur un compte WhatsApp Web — normal : ces comptes n'ont pas de catalogue, leurs modèles s'écrivent dans « Modèles locaux ».

Voir aussi

• Séquences — où les modèles servent
• Confirmation COD — le modèle à deux boutons
• Rotation — pourquoi un modèle local suit le groupe
• Comptes — d'où viennent les modèles