Le CMO vous l’affirme, convaincu : nous avons un programme de fidélisation et il fonctionne. Des points, une carte, des remises par niveaux, le classique. En apparence, tout est en ordre. Puis vous posez une question très simple : ce client qui cumule des points en magasin peut-il consulter son solde dans l’appli ? En général, il n’y a pas de réponse. Ce n’est pas que le programme soit en panne, à proprement parler. C’est qu’il ne fonctionne que dans l’un des endroits où le client achète, et aujourd’hui presque personne ne s’en tient à un seul canal de vente. Une carte qui vit en magasin mais n’existe pas sur le site web, ou l’inverse, ce qui arrive aussi, est probablement l’erreur la plus courante dans le retail de taille moyenne. Et la plus difficile à repérer à temps, car elle n’apparaît dans aucun rapport tant que quelqu’un ne décide pas de regarder vraiment, sans se presser, ce qui se passe. Voici le premier cas de la série Autopsie de la fidélisation : le diagnostic, la cause réelle et l’ordonnance pour comprendre pourquoi votre programme vit coupé en deux sans que personne ne l’ait jamais voulu. Car, au fond, personne ne conçoit un programme pour qu’il ne fonctionne que la moitié du temps.
Le diagnostic : un programme que le client ne peut pas toucher du doigt
Imaginez un client régulier d’une chaîne de mode. Deux ans à cumuler des points en magasin. Carte physique, numéro de membre, la sensation vague mais bien réelle d’avoir quelque chose de côté. Un dimanche quelconque, il achète sur le site web, arrive au paiement et ne trouve aucune trace de son solde. Il ouvre l’appli et n’y trouve rien non plus. Il appelle le service client et le conseiller ne peut pas vraiment l’aider, car ces données ne vivent que dans la caisse du magasin physique. En pratique, ce client a deux programmes de fidélisation du même distributeur qui ne communiquent pas entre eux. L’un pour le magasin, et un autre, nettement plus pauvre, pour tout le reste. Et ce « tout le reste » est, année après année, là où il dépense le plus.
Ce n’est pas vraiment nouveau. Il existe un précédent bien connu : la carte de fidélité classique, celle des tampons et de la remise en caisse, n’a jamais capté toute l’activité d’un client.
30-40 %
des transactions, c’est le maximum qu’une carte de fidélité classique ait jamais réussi à capter ; le reste n’était pas suivi, sans nom et sans moyen de relance.
Le programme de points d’aujourd’hui hérite de cette même limite, avec une nuance : le canal invisible n’est plus « ce qui n’a jamais été enregistré », mais « ce qui a été enregistré au mauvais endroit ». Le client cumule bien des points, mais pas là où il voudra ensuite les utiliser. Et voici le plus curieux : le symptôme n’apparaît dans aucun tableau de bord des ventes. Le chiffre d’affaires continue d’entrer, le programme semble vivant, aucune alarme ne se déclenche. Le problème ne devient visible que lorsque quelqu’un se met à mesurer la participation réelle : combien de clients inscrits ont utilisé quelque chose au cours des douze derniers mois, combien ont acheté sur plus d’un canal. C’est alors que les chiffres cessent de concorder. Et le plus étrange, vraiment surprenant quand on y réfléchit, c’est que personne ne ment. Le magasin voit le programme fonctionner parce que, sur ce canal, il fonctionne. L’e-commerce ne le compte même pas dans ses indicateurs car, de son point de vue, ce programme n’existe tout simplement pas : il n’apparaît pas à son paiement, il n’entre pas dans ses chiffres de conversion. Chaque équipe a raison sur les données qu’elle gère, et c’est précisément le piège. Le problème ne vit dans aucun rapport en particulier ; il vit dans l’écart entre les rapports.
Pourquoi cela arrive : la fidélisation comme système greffé sur la caisse
La cause est rarement la négligence ; c’est l’architecture, et une architecture ancienne. Le programme de fidélisation est né, chez la plupart des distributeurs, comme un module du système de caisse : un complément du terminal POS pour additionner des points quand quelqu’un payait en magasin. À l’époque, cela avait tout son sens, car presque toute l’activité passait par là. Le problème, c’est que l’activité a changé et que le programme est resté figé. Le e-commerce est arrivé, puis l’appli, puis WhatsApp comme canal d’achat et d’assistance, et le module de fidélisation a continué de vivre exactement là où il était né : sur le POS. C’est un défaut de conception, pas un manque d’intention, et il faut le dire clairement, car on le lit souvent à l’envers. Personne ne s’est réveillé un jour en décidant « ne récompensons que les clients du magasin ». Tout simplement, le système qui gère l’avantage n’a jamais été conçu pour dialoguer avec le paiement en ligne, et le relier après coup, sur un système qui n’y était pas destiné, s’avère coûteux, lent et, souvent, n’est jamais vraiment bien fait. Et c’est là que beaucoup de distributeurs restent bloqués pendant des années : la solution « évidente », intégrer manuellement le système de points actuel au e-commerce, implique généralement de toucher au POS, à l’ERP et au moteur de prix de la boutique en ligne. Ce n’est pas que personne ne veuille corriger. C’est que le faire ainsi devient un projet qui se dispute budget et temps IT avec d’autres priorités plus urgentes. Et pendant ce temps, le correctif n’arrive jamais. Le véritable changement de paradigme est ailleurs : l’avantage n’est pas calculé ni appliqué dans un module isolé, mais en consultant les données du client en temps réel, au moment même du paiement, quel que soit le canal sur lequel il a lieu. Quand la fidélisation vit dans la passerelle transactionnelle du paiement, et non dans un recoin du système de caisse, peu importe que le client paie en magasin, sur le web ou depuis son téléphone : le moteur consulte les mêmes données. Il applique le même avantage dans l’un quelconque des trois endroits.
Le coût silencieux d’un programme fragmenté
Le plus coûteux dans cette erreur n’est pas technique, c’est la confiance, et c’est plus grave qu’il n’y paraît. Un client qui ne peut pas consulter son solde, ou qui découvre que ce qu’il a gagné en magasin ne vaut rien en ligne, apprend vite une leçon désagréable : on ne peut pas se fier à ce programme, mieux vaut ne pas compter dessus. Il cesse de consulter son solde, cesse d’attendre l’avantage, et l’entreprise perd exactement ce qu’un programme de fidélisation est censé générer : une raison de revenir. De plus, ce client finit par appeler le service client pour demander quelque chose qu’il devrait pouvoir résoudre seul. « Combien ai-je de points ? » ne devrait pas nécessiter un conseiller au bout du fil. Et chaque fois que c’est le cas, il y a un coût opérationnel que personne n’a budgété pour le programme de fidélisation. Et puis il y a les données, qui sont peut-être le dommage le moins visible de tous. Si le système de points vit séparé du reste de l’activité, le comportement du client se retrouve lui aussi scindé en deux enregistrements qui ne communiquent pas entre eux. L’équipe marketing ne peut pas savoir si le même client qui achète en magasin achète aussi en ligne, car le système, littéralement, l’ignore. Et cela frappe exactement là où cela fait le plus mal au CMO : la CLTV et la marge. Si l’on ne voit pas le client dans son ensemble, on ne peut pas savoir ce qu’il vaut réellement, ni quel effort de rétention il mérite. Un client qui achète sur les deux canaux peut apparaître, dans des rapports séparés, comme deux clients moyens au lieu d’un très bon client, et les décisions d’investissement en fidélisation prises avec cette demi-image ont tendance à se tromper presque par définition, aussi bien pensée que la stratégie paraisse sur le papier.
L’ordonnance : une vraie fidélisation omnicanale
La solution n’est pas de « faire plus d’efforts » avec le programme actuel. C’est de changer l’endroit où vivent les données du client. Un portefeuille client unifié résout le problème à la racine : un espace numérique unique qui réunit le solde, l’historique et les avantages du client, accessible depuis différents environnements, intégré à l’appli du distributeur, à une appli en marque blanche, via Apple Wallet ou Google Wallet avec Mobile Pass, ou directement depuis le navigateur, mais affichant toujours le même contenu, la même expérience, mise à jour en temps réel. Concrètement, cela signifie que les points gagnés en magasin peuvent être utilisés sur le site e-commerce et inversement, sans délai ni synchronisation manuelle, avec le même solde visible sur tous les points de contact que le client souhaite consulter. Celui qui appelait pour demander son solde n’a plus ce problème : il peut le consulter lui-même, instantanément, d’où cela lui convient le mieux. Prenons un cas concret : un client achète en magasin un samedi et gagne des points. Le dimanche, depuis son canapé, il va sur le site du même distributeur et voit ce solde mis à jour dans son compte, pas une version de quelques jours plus tôt, le vrai. Il utilise une partie de ces points sur un achat en ligne. Le système les déduit de ce même solde unique, et non d’une copie séparée. Si cette personne retourne dans le magasin physique la semaine suivante, le solde que le caissier voit en caisse est, là encore, le même. Il n’y a pas de « version magasin » et de « version web » du client. Il y a un client, avec un solde, visible de partout. Et cette continuité est exactement ce qu’un client entend par « être inscrit à un programme de fidélisation ». Ce n’est pas demander beaucoup. C’est simplement le minimum que l’on attend de quelque chose qui porte ce nom. Il n’est même pas nécessaire de toucher à l’ERP ou au moteur de prix du e-commerce pour y parvenir : l’avantage est calculé et appliqué au paiement, via une passerelle, en consultant les données existantes au moment du règlement. Le marketing gagne en autonomie sur le programme sans dépendre d’un long projet d’intégration, et l’équipe IT n’a pas à ouvrir un nouveau ticket de développement chaque fois qu’une règle du programme change. Et cela ne nécessite pas le projet d’un an que beaucoup d’équipes redoutent. Les projets d’entreprise de CDP plus fidélisation avancent généralement en cycles de 8 à 18 mois. Une intégration construite sur une seule API de paiement, en revanche, avance en quelques semaines : la plupart des cas sont mis en production en 4 à 12 semaines, selon l’intégrateur du point de vente du distributeur. Ce n’est pas une promesse marketing de plus. C’est la différence entre réécrire de zéro le système de caisse et brancher une passerelle par-dessus.
Comment savoir si votre programme survivrait à cette autopsie
Avant de supposer que cela ne vous concerne pas, il vaut la peine de vous poser cinq questions précises. Aucune ne demande d’analyse technique approfondie : on y répond en observant l’expérience réelle du client, pas la fiche produit du fournisseur actuel.
- Le client voit-il le même solde de points en magasin, dans l’appli et sur le site web, sans écart ?
- Ce qui est gagné en caisse peut-il être utilisé en ligne, et ce qui est gagné en ligne peut-il être utilisé en caisse ?
- Le service client peut-il consulter le solde de n’importe quel client, quel que soit le canal d’achat utilisé ?
- Le marketing peut-il lancer un nouvel avantage sans ouvrir de ticket IT pour toucher au système de caisse ?
- Savez-vous, données réelles à l’appui, quel pourcentage de vos clients inscrits a utilisé quelque chose au cours des douze derniers mois ?
Si l’une de ces questions vous fait réfléchir au lieu de répondre oui immédiatement, votre programme présente, au minimum, une version de ce même problème. Et il n’y a aucun mal à l’admettre : c’est de loin la plus courante des quatre erreurs que nous aborderons dans cette série, ce qui, vu autrement, est en réalité une bonne nouvelle. Cela signifie que la solution a déjà fait ses preuves. Il n’y a rien à inventer de zéro.
Une fidélisation que le client ne peut pas toucher du doigt ne construit pas de fidélité. Voici le premier cas de l’Autopsie de la fidélisation, la série dans laquelle Wapping passe en revue, cas par cas et sans citer de marques, les erreurs les plus courantes et les plus silencieuses des programmes de fidélisation dans le retail. À suivre : ce qui se passe lorsqu’une remise est envoyée à toute la base clients de la même façon, sans distinguer ceux qui en avaient réellement besoin de ceux qui n’en avaient pas besoin.