Programme fidélité Klaviyo : Smile.io, LoyaltyLion ou Yotpo

Le choix d'un outil de fidélité se joue rarement sur la brochure. Il se joue sur ce qui arrive réellement dans Klaviyo : quels événements, sous quels noms, avec quelles propriétés de profil, et à quelle fréquence. Une marque qui compare Smile.io, LoyaltyLion et Yotpo Loyalty & Referrals sur les fonctionnalités de l'interface loyalty se trompe de critère. Ce qui compte pour le CRM, c'est la qualité du flux de données côté ESP, parce que c'est de là que sortent les segments, les flows et le revenu.

Cet article prend le problème par le bout Klaviyo : ce que la plateforme attend d'une intégration loyalty, ce qui est réellement documenté pour chaque acteur, et la méthode pour cadrer votre choix avant de signer quoi que ce soit.

Ce que Klaviyo attend d'une plateforme de fidélité

Klaviyo publie une documentation développeurs dédiée à l'intégration d'une plateforme loyalty. C'est le document de référence, et il vaut la peine d'être lu même si vous ne codez pas une ligne : il définit le standard sur lequel juger n'importe quel fournisseur.

La taxonomie d'événements officielle

Le guide d'intégration loyalty de Klaviyo liste 14 événements attendus, répartis en deux familles.

Onze événements sur les points, les rewards et les paliers :

• Loyalty Member Enrolled
• Points Earned
• Points Redeemed
• Points Expiring Soon
• Points Expired
• Reward Earned
• Reward Redeemed
• Reward Expiring Soon
• Tier Upgraded
• Tier Downgraded
• Tier Approaching

Trois événements sur le parrainage :

• Referral Sent
• Referral Started
• Referral Completed

Cette liste est votre grille de lecture. Chaque événement manquant est un flow que vous ne pourrez pas construire. Pas de Points Expiring Soon, pas de relance avant expiration des points, donc pas de réactivation sur ce levier. Pas de Tier Approaching, pas de campagne "il vous manque X pour passer au palier supérieur", qui est pourtant l'un des rares mécanismes de fidélité qui déclenche une commande incrémentale plutôt que de subventionner une commande déjà décidée.

Quand vous cadrez un fournisseur, posez la question dans ces termes exacts : lesquels des 14 événements poussez-vous dans Klaviyo, et sous quel nom ? La réponse tient sur une ligne ou elle n'existe pas.

Une convention de nommage volontairement asymétrique

Le point le plus intéressant de la doc Klaviyo est une règle qui paraît anecdotique et qui ne l'est pas : les propriétés de profil sont préfixées du nom de la plateforme, les événements ne le sont pas. La documentation est explicite : "Use Title Case property names prefixed with your platform's name" et "Event names are not prefixed with your platform name".

Concrètement dans les données : un événement s'appelle Points Earned, quel que soit le fournisseur, tandis qu'une propriété de profil porte la marque de son émetteur. C'est ce qui permet à deux intégrations loyalty de cohabiter sur un même profil sans écraser leurs données respectives, ce qui compte lors d'une migration d'un outil vers un autre, période pendant laquelle les deux tournent en parallèle.

Côté opérationnel, ça veut dire que vos conditions de flow construites sur les métriques restent portables d'un fournisseur à l'autre, alors que vos segments construits sur les propriétés de profil devront être réécrits. Une bonne raison de bâtir vos automatisations sur les événements en priorité, et de réserver les propriétés à l'affichage et à la segmentation avancée.

Trois endpoints, trois scopes, zéro magie

Techniquement, une intégration loyalty Klaviyo repose sur trois appels seulement, listés dans la même documentation :

Et trois scopes OAuth : profiles:read pour retrouver un profil existant avant écriture (matching sur email et téléphone), profiles:write pour poser les propriétés, events:write pour émettre les événements. Un fournisseur qui vous demande davantage de permissions sur votre compte mérite une question.

Si votre programme de fidélité est maison ou branché sur un back-office custom, c'est exactement le chemin décrit dans notre guide sur l'envoi d'events Klaviyo depuis votre stack.

Les pièges techniques qui cassent une intégration loyalty

Trois points de la doc développeurs méritent d'être connus côté CRM, parce que ce sont eux qui expliquent les incidents.

Les jetons tournent. Les access tokens Klaviyo expirent au bout d'une heure et les refresh tokens changent à chaque utilisation. La documentation prévient : il faut persister le dernier refresh token après chaque appel de rafraîchissement, sous peine de perdre l'intégration au refresh suivant. Symptôme typique côté marque : les points continuent de s'accumuler dans l'outil loyalty mais plus rien n'arrive dans Klaviyo, sans aucune alerte. Si vos flows fidélité tombent silencieusement à zéro, c'est la première chose à vérifier.

Les quotas d'API sont partagés. Les limites de débit s'appliquent par compte et non par application. Plusieurs apps installées sur le même compte Klaviyo puisent dans le même budget d'appels. Une marque qui empile un outil loyalty, un outil d'avis, un outil de fidélité en test et un connecteur ERP maison ne dispose pas de quatre budgets, mais d'un seul. Klaviyo indique que les limites standard absorbent un volume loyalty typique sans effort particulier, et situe le seuil de renégociation au-delà de 10 millions d'événements par jour ou de centaines de milliers de membres inscrits par marchand, la hausse s'obtenant alors par endpoint et par compte auprès du support et du CSM.

Le backfill charge un état, pas un historique. À l'installation, la reprise passe par le job d'import de profils en masse, et la doc est catégorique : "This is for state, not history. Don't try to replay years of events through it." Vous récupérez le solde de points et le palier courant de vos membres. Vous ne récupérez pas trois ans d'historique d'événements. Toute segmentation rétroactive du type "clients ayant utilisé un reward au cours des douze derniers mois" démarre donc à la date d'installation. Prévoyez-le dans votre plan de mesure plutôt que de le découvrir en construisant vos premiers segments.

Ce qui est réellement documenté par fournisseur

Ici, il faut séparer ce que Klaviyo documente officiellement de ce qui relève du discours commercial. Klaviyo explique lui-même la règle dans sa page consacrée à LoyaltyLion : les intégrations construites par Klaviyo, dites natives, ont une documentation dans le centre d'aide, les apps tierces n'en ont pas, leur documentation vivant sur leur fiche marketplace. L'absence de page détaillée n'est donc pas un verdict de qualité, mais elle change la charge de preuve qui vous incombe pendant le cadrage.

Smile.io et Customer Hub

Smile.io est l'un des deux fournisseurs documentés dans la section Customer Hub du centre d'aide Klaviyo. La connexion est d'une simplicité rare : d'après la procédure officielle, il suffit de sélectionner Smile.io dans le menu déroulant des fournisseurs sous la rubrique Loyalty des Extensions de Customer Hub, puis d'enregistrer. Aucune clé API à manipuler.

Ce que le référentiel d'affichage précise sur les blocs rendus dans Customer Hub :

• l'icône de palier VIP (par exemple Silver VIP)
• le nombre de points de fidélité
• le meilleur reward disponible
• une barre de progression vers le prochain meilleur reward
• les rewards disponibles
• le lien de parrainage individuel
• les moyens de gagner des points configurés dans Smile.io

Deux comportements à anticiper côté expérience : un profil qui n'est pas membre du programme ne voit aucune donnée de fidélité, et un visiteur non authentifié se voit proposer de se connecter pour accéder à ses informations. Ça se traduit en cadrage produit : si votre Customer Hub est votre page compte, les non-membres tombent sur une zone vide, ce qui est une opportunité d'acquisition de membres autant qu'un risque de page pauvre.

Attention à ne pas surinterpréter cette page : elle décrit ce que Customer Hub affiche, pas la taxonomie d'événements que Smile.io pousse dans Klaviyo. Les noms exacts des métriques créées côté Smile.io ne sont pas listés dans les pages ouvertes. À demander au fournisseur, grille des 14 événements en main.

Yotpo Loyalty & Referrals

Yotpo est le second fournisseur documenté pour Customer Hub, avec un prérequis structurant. D'après la page d'intégration Klaviyo, il vous faut un compte Yotpo Loyalty & Referrals actif, Customer Hub en ligne sur le site, votre API Key et votre GUID Yotpo, et surtout l'intégration Yotpo vers Klaviyo déjà active et gérée depuis Yotpo pour synchroniser les propriétés de profil et les événements.

C'est un point d'architecture à retenir : dans ce montage, le flux de données ne part pas de Klaviyo. Klaviyo consomme ce que Yotpo pousse. Votre plan de mesure se cadre donc côté Yotpo, et le support de premier niveau sur un événement manquant est côté Yotpo aussi.

Les propriétés de profil Yotpo Loyalty exploitables dans Klaviyo sont nommées swell_point_balance, swell_vip_tier_name, swell_referral_link et swell_has_account. Ce sont vos briques de segmentation immédiates : un segment sur swell_vip_tier_name alimente directement une logique VIP dans Klaviyo, un segment sur swell_point_balance permet de cibler les soldes dormants.

Notez au passage que ce nommage en minuscules avec underscore ne suit pas la convention Title Case préfixée recommandée par la doc développeurs. Ça n'a rien de bloquant, mais ça illustre qu'un fournisseur historique peut avoir des conventions antérieures à la recommandation actuelle. Vérifiez toujours les noms réels dans votre compte plutôt que de les déduire d'un guide.

LoyaltyLion

LoyaltyLion existe sur la marketplace Klaviyo. Au 7 septembre 2026, il ne figure pas parmi les fournisseurs documentés dans la section Customer Hub du centre d'aide Klaviyo, qui ne recense que Yotpo et Smile.io. Comme expliqué plus haut, ça s'explique par la politique de documentation de Klaviyo : les apps tierces documentent leur intégration de leur côté.

Ce que ça implique pour vous : les événements, propriétés de profil et flows éventuellement fournis par LoyaltyLion ne sont pas vérifiables sur une page Klaviyo. Ils sont peut-être excellents. La démarche honnête consiste à les faire confirmer par écrit par l'éditeur pendant le cadrage, avec la liste des 14 événements comme document de travail, plutôt que de trancher sur une impression.

La méthode de cadrage en 7 questions

Voici la grille que nous passons en amont d'un choix d'outil loyalty, quand la décision doit tenir compte du CRM et pas seulement du programme de fidélité lui-même.

1. Quels événements Klaviyo poussez-vous, avec leurs noms exacts ? Comparez à la liste des 14. Chaque absence se traduit en flow impossible.
2. Quelles propriétés de profil écrivez-vous, avec leurs noms exacts ? Ce sont vos futurs segments. Demandez un échantillon de profil réel, pas une capture marketing.
3. Le flux part-il de vous ou de Klaviyo ? Le cas Yotpo montre que la réponse change l'endroit où l'on débogue et l'endroit où l'on cadre le plan de mesure.
4. Que se passe-t-il au backfill ? Vous récupérez un état, pas un historique. Actez la date de démarrage réelle de votre segmentation loyalty.
5. Quelle latence entre l'action et l'événement ? Un Points Earned qui arrive avec plusieurs heures de retard rend inutilisable tout flow temps réel adossé à la fidélité.
6. Quel est l'impact sur votre budget d'appels API ? Les limites sont par compte. Recensez tout ce qui écrit déjà dans Klaviyo avant d'ajouter une brique.
7. Qui répond en cas de rupture de flux ? Trois interlocuteurs possibles, l'éditeur loyalty, Klaviyo, votre intégrateur. Ça se tranche avant l'incident, pas pendant.

Les questions de prix, de plans et de seuils de commandes ne figurent pas dans cette grille pour une raison simple : aucune page tarifaire éditeur n'a pu être vérifiée pour la rédaction de cet article, et nous ne citons pas de chiffre que nous n'avons pas lu à la source. Demandez la grille tarifaire à jour directement aux éditeurs, en précisant votre volume de commandes mensuelles.

Ce que vous faites de ces données une fois qu'elles arrivent

Brancher l'outil ne produit pas de revenu. Ce qui produit du revenu, c'est ce que vous construisez avec les événements une fois qu'ils sont dans Klaviyo.

Les quatre usages qui rentabilisent le plus vite une intégration loyalty :

• La relance avant expiration des points. Elle s'appuie sur Points Expiring Soon et cible un stock de valeur déjà acquis par le client. C'est le levier le plus proche d'une réactivation de clients dormants avec un motif légitime, non promotionnel.
• Le palier presque atteint. Tier Approaching alimente un message qui augmente la valeur moyenne de commande sans remise supplémentaire.
• L'enrichissement des segments existants. Le solde de points et le palier deviennent des dimensions supplémentaires dans vos segments RFM et dans votre approche VIP. Un gros palier avec une récence dégradée n'est pas le même client qu'un petit palier récent.
• La couche fidélité dans le post-purchase. Rappeler les points gagnés dans la séquence post-achat transforme un email transactionnel en boucle de réengagement.

Ces usages ne fonctionnent que si la base est saine en amont. Un programme de fidélité branché sur une liste mal segmentée et une délivrabilité fragile amplifie les problèmes existants au lieu de les résoudre. Si votre socle n'est pas au niveau, notre scorecard lifecycle en 50 points est le meilleur point de départ, avant l'intégration loyalty.

Si vous voulez faire cadrer ce chantier par une équipe qui travaille Klaviyo au quotidien, c'est le métier de notre agence Klaviyo.

FAQ

Faut-il choisir un outil loyalty documenté par Klaviyo ?

Ce n'est pas un critère suffisant. Klaviyo ne documente dans son centre d'aide que ses intégrations natives, les apps tierces documentant les leurs de leur côté. La bonne démarche consiste à demander à chaque éditeur la liste exacte des événements et des propriétés qu'il pousse dans Klaviyo, et à la comparer aux 14 événements de la taxonomie officielle.

Peut-on faire tourner deux outils de fidélité en parallèle sur Klaviyo ?

C'est ce que la convention de nommage rend possible : les propriétés de profil sont préfixées du nom de la plateforme, donc deux intégrations n'écrasent pas leurs données. Attention en revanche aux quotas d'API, qui s'appliquent par compte et non par application : deux outils partagent le même budget d'appels.

Récupère-t-on l'historique de fidélité à l'installation ?

Non. Le backfill Klaviyo passe par le job d'import de profils en masse et charge l'état courant des membres, pas l'historique d'événements. La documentation développeurs déconseille explicitement de rejouer des années d'événements par ce canal. Votre segmentation sur les événements loyalty démarre donc à la date d'installation.

Pourquoi mes flows de fidélité s'arrêtent-ils sans erreur visible ?

Le premier suspect est l'authentification. Les access tokens Klaviyo expirent au bout d'une heure et les refresh tokens changent à chaque utilisation : si le dernier refresh token n'est pas persisté, l'intégration se casse au rafraîchissement suivant. Les points continuent alors de s'accumuler côté outil loyalty sans qu'aucun événement n'arrive dans Klaviyo.

Quel budget prévoir pour Smile.io, LoyaltyLion ou Yotpo ?

Les grilles tarifaires de ces éditeurs n'ont pas été vérifiées à la source pour cet article, et nous ne publions pas de chiffre que nous n'avons pas lu. Demandez leur grille à jour directement aux éditeurs en indiquant votre volume de commandes mensuelles, et intégrez au calcul le coût de mise en place côté CRM, qui est rarement dans le devis de l'outil.