.avif)
RewardPulse automatise le contrôle des preuves d'achat
RewardPulse conçoit des programmes de fidélité et de stimulation commerciale pour d'autres entreprises. Fiabiliser la validation de chaque preuve d'achat à grande échelle s'est révélé bien plus complexe que prévu.
.avif)
RewardPulse est une entreprise française qui conçoit et pilote des dispositifs d'engagement pour le compte d'autres entreprises : programmes de fidélité destinés aux clients finaux, opérations de stimulation commerciale pour des réseaux de vente, programmes de parrainage ou plateformes de reconnaissance interne. Filiale de Smartbox, RewardPulse met à disposition un catalogue de récompenses et d'expériences à échanger contre des points, ainsi qu'un accompagnement pour concevoir et faire vivre ces dispositifs dans la durée. Ses programmes sont déployés pour des marques présentes dans plusieurs pays européens, ce qui impose de composer avec des bénéficiaires, des enseignes et des habitudes d'achat très différentes d'un marché à l'autre.
Un geste simple pour le client, un contrôle lourd pour RewardPulse
Derrière la plupart des programmes que conçoit RewardPulse se cache une mécanique identique : un client, un commercial ou un revendeur réalise un achat, puis transmet un justificatif, ticket de caisse ou facture, pour débloquer ses points ou sa récompense. Cette preuve d'achat est la pièce qui déclenche tout le reste du programme : sans validation, pas de points, pas de récompense, et un bénéficiaire mécontent. Tant que les campagnes restaient limitées, relire chaque preuve d'achat à la main, enseigne par enseigne, ligne par ligne, restait tenable pour les équipes de RewardPulse. Mais dès qu'un programme change d'échelle, comme lors du lancement d'une campagne pour le réseau d'entretien automobile Speedy, ce contrôle manuel devient le goulot d'étranglement de tout le dispositif : c'est lui qui fixe le délai entre l'achat du client et la réception de sa récompense.
Pourquoi une preuve d'achat est un document difficile à lire automatiquement
Un ticket de caisse n'a rien d'un document standardisé. Chaque enseigne l'imprime avec sa propre mise en page, ses propres abréviations et son propre ordre de champs : le code produit apparaît parfois sous forme de code EAN à treize chiffres, parfois sous un libellé interne à l'enseigne, parfois sous les deux à la fois. Le montant qui compte pour valider un achat peut être le total TTC, le montant HT, ou le prix d'un seul article isolé au milieu d'un panier de plusieurs dizaines de lignes. Le bénéficiaire, de son côté, ne photographie pas son ticket dans les conditions d'un scanner de bureau : il le prend en photo sur un coin de table, avec un angle, une ombre portée ou un pli qui déforme le texte. Le papier thermique des tickets de caisse s'efface en outre avec le temps, ce qui rend certains justificatifs à peine lisibles au moment où ils sont soumis, parfois plusieurs semaines après l'achat.
Pour un programme déployé dans plusieurs pays s'ajoutent des formats de date différents, des devises différentes et des enseignes locales que le modèle d'extraction doit apprendre à reconnaître au même titre qu'une enseigne nationale déjà connue. Enfin, un programme de fidélité doit composer avec un risque structurel : un même ticket soumis deux fois, volontairement ou non, pour obtenir deux fois la même récompense. Un contrôle qui se contente de lire les champs sans comparer chaque nouveau justificatif à ceux déjà traités laisse cette faille grande ouverte.
La solution mise en place avec Koncile
RewardPulse a construit son contrôle des preuves d'achat autour de l'extraction de données de Koncile. Les justificatifs sont collectés par plusieurs canaux, scan, e-mail ou dépôt direct dans l'application du programme, puis transmis à Koncile par API pour être analysés. Le modèle dédié aux reçus, déjà entraîné sur ce type de document, retrouve les champs utiles : code produit ou EAN, libellé, quantités achetées, montants HT et TTC, enseigne et date d'achat. Ce modèle reste ajustable directement par les équipes de RewardPulse, en langage courant plutôt qu'en règles techniques, ce qui leur permet d'ajouter un champ ou de préciser une consigne dès qu'une nouvelle campagne l'exige.
Un champ de validation détermine ensuite si la preuve d'achat est conforme : les justificatifs valides sont acceptés, ceux qui manquent d'un élément déclenchent une demande de complément, et ceux qui ne correspondent pas aux règles du programme sont rejetés de façon transparente, avec le motif du rejet. Cette approche s'appuie sur les briques d'extraction de données et d'API OCR de Koncile, pensées pour transformer un document image en champs structurés directement exploitables par une application tierce.
Qui fait quoi entre RewardPulse et Koncile
Côté RewardPulse, c'est l'équipe technique, autour de son CTO Bastien Benloulou, qui a pris en charge l'intégration : génération d'une clé API, connexion du flux de preuves d'achat au modèle d'extraction, puis sécurisation du webhook qui renvoie le statut de chaque document vers la plateforme du programme. Ce statut, en cours de traitement, traité ou identifié comme duplicata, circule ainsi en temps réel, sans que quiconque ait besoin d'aller le consulter manuellement dans un second outil.
Côté Koncile, l'accompagnement a porté sur le paramétrage du modèle d'extraction pour ce type de document, la documentation de l'API et du webhook, et le suivi de la montée en charge : le volume de preuves d'achat à traiter a progressivement augmenté à mesure que de nouvelles campagnes, comme celle lancée avec Speedy, sont venues s'ajouter au périmètre, sans qu'aucune limite de volume n'ait eu à être renégociée en cours de route.
Ce que l'automatisation a changé pour RewardPulse
La première campagne à fonctionner intégralement sur ce circuit automatisé a été celle lancée avec Speedy à l'automne 2025 : les preuves d'achat soumises par les clients du réseau ont été extraites, validées et transmises à la plateforme RewardPulse sans relecture manuelle systématique. Pour les équipes de RewardPulse, le changement se mesure moins en heures gagnées qu'en nature du travail restant : au lieu de relire chaque ticket pour vérifier une enseigne ou un montant, elles interviennent surtout sur les cas limites remontés par le contrôle automatique, c'est-à-dire les justificatifs ambigus ou incomplets. Ce socle a ensuite servi de base à d'autres campagnes clientes, avec des volumes de justificatifs qui peuvent varier fortement d'une opération à l'autre sans remettre en cause le circuit de traitement.
Les prochaines étapes
RewardPulse évalue désormais l'extension de ce circuit à des programmes déployés dans plusieurs pays européens, ce qui suppose d'élargir le modèle d'extraction à de nouvelles enseignes et de nouveaux formats de tickets. La mécanique de collecte, d'extraction et de validation reste applicable quel que soit le marché dès lors que le modèle a été entraîné sur les documents locaux, sur le même principe que ce qui a été mis en place chez Toyota Assurances, où le dossier de souscription arrive également saisi et contrôlé avant d'être repris par un gestionnaire.
Questions fréquentes






.png)


.avif)

.avif)


