Migrer sa plateforme de cartes cadeaux sans interruption : soldes, données, continuité

Un programme de cartes cadeaux et de fidélité peut changer de plateforme sans que les clients s'en aperçoivent — mais uniquement si les soldes, le stock de cartes et les formats de données sont cartographiés avant tout déplacement.

Une migration est d'abord un exercice de cartographie

Ogloba a construit des parcours clé en main pour les distributeurs qui transfèrent depuis une plateforme existante leurs programmes de cartes cadeaux et de fidélité, les soldes actifs et le stock de cartes. Le travail commence par la mise en correspondance des données de l'ancien système avec le schéma Ogloba, ce qui produit la conception de l'extraction et du chargement — en reliant les formats hérités aux exigences du nouveau système. Une migration programmatique peut passer par de nombreuses phases, mais au minimum elle lit dans l'ancien système et écrit dans le nouveau. La contrainte pratique est rarement technique. La continuité dépend de la coopération de l'ancien prestataire, ou de la capacité de la DSI du distributeur à extraire elle-même les données.

Quand la conversion n'est pas la réponse

Tous les programmes n'ont pas besoin d'être convertis. Lorsque la réglementation locale impose le maintien d'un processeur tiers, le changement porte sur les interfaces, pas sur les données. Un programme de cartes cadeaux mobiles livré à une grande chaîne de distribution chinoise en 2013 fonctionnait ainsi : une API dédiée reliait le système de caisse Wincor à Ogloba, tandis qu'un web service China Union Pay gérait la consultation des soldes et les requêtes de transaction. En caisse, le terminal transmettait le PAN de la carte et le numéro de mobile du porteur à Ogloba, qui livrait la carte sur le téléphone — ou envoyait un lien SMS vers l'app store si nécessaire.

Le risque de migration est avant tout un problème de cartographie des données. Réglez-le tôt et le client ne verra jamais le changement.

FAQ

Que faut-il cartographier avant de déplacer le moindre solde ?

Chaque format de données hérité est d'abord relié au schéma Ogloba. Cette cartographie produit la conception de l'extraction et du chargement, et couvre les soldes actifs, le stock de cartes et les règles de programme qui y sont attachées.

Qu'est-ce qui retarde le plus souvent une migration de plateforme ?

Pas la technique. La contrainte habituelle consiste à sortir les données du système en place : soit l'ancien prestataire coopère, soit la DSI du distributeur réalise elle-même l'extraction.

Dans quels cas convertir les données n'est-il pas la bonne approche ?

Lorsque la réglementation locale impose le maintien d'un processeur tiers. Le programme change alors d'interfaces plutôt que de données, et le processeur existant continue de fonctionner en dessous.

Comment une caisse peut-elle rester inchangée alors que la plateforme derrière elle change ?

Grâce à une API dédiée entre le terminal de caisse et la plateforme. Dans un déploiement chez un distributeur chinois, la caisse transmettait le PAN de la carte et le numéro de mobile du porteur à Ogloba, qui livrait la carte sur le téléphone sans modifier le parcours en caisse.