Opération Fidélité,la plateforme de fidélité et de jeux par QR code pour la restauration
SaaS de fidélisation par QR code et avis clients
Une plateforme SaaS de fidélité, de jeux et d’avis clients pour les restaurants.
En préproduction
Client
Client non cité
Période
juin 2026 à aujourd’hui
Rôle
Développeur full-stack, de l’API au déploiement
Type
Plateforme SaaS de fidélisation pour restaurants
Statut
En préproduction, mise en production imminente
Le butin :Une plateforme de fidélité complète pour restaurants, du jeu par QR code à l’abonnement facturé par établissement, livrée de l’API au déploiement.
Opération Fidélité est une mission freelance : la refonte complète d’une plateforme de fidélité et de jeux pour les restaurants, sur un socle neuf. Je réalise toute la partie technique, du back-end Laravel au front Vue, jusqu’à l’infrastructure et au déploiement. Le projet a démarré en juin 2026. La nouvelle version est en préproduction et sa mise en production est imminente.
La cible · Le problème
Les restaurants et fast-foods veulent faire revenir leurs clients, mais les outils de fidélité sont souvent lourds pour des équipes qui n’ont pas de temps à leur consacrer.
Il fallait un back-office qu’un gérant puisse prendre en main seul, et un modèle d’abonnement que le client puisse faire évoluer sans développeur.
La nouvelle version devait aussi gérer plusieurs établissements par compte, chacun avec son propre abonnement, et ajouter de nouveaux modules : réputation en ligne, marketing, création de visuels, cartes de fidélité dans le portefeuille du téléphone.
Le plan · La solution
Le commerçant crée des jeux accessibles par QR code. Le client scanne, joue, gagne un lot et laisse ses coordonnées, dans le respect du RGPD.
Depuis son back-office, le commerçant gère ses campagnes de jeu, sa base clients, son programme de fidélité et ses campagnes par e-mail, SMS et notification. Il suit ses avis en ligne et y répond avec une proposition rédigée par IA. Il crée ses visuels promotionnels avec le QR code déjà intégré. Un tableau de bord consolide tous les établissements d’un même compte.
Chaque palier d’abonnement débloque ses propres fonctionnalités, et la facturation se fait par établissement via Stripe. Une console d’administration permet au client de piloter les paliers, les utilisateurs et la facturation.
Parcours clientscan du QR code, jeu, lotBack-office commerçantVue 3Console d’administrationpaliers, facturationServeur du client · DockerAPI REST Laravelversionnée, organisée par domaine métierAccès par paliermenu, routeur et APIBase relationnelleétablissements, paliers, clientsCache et filesCatalogue des fonctionnalitésconfigurationDéploiement automatiqueGitHub Actions, DockerStripeabonnement par établissementService d’IAréponses aux avisAvis GoogleGoogle PlacesNotificationsOneSignalCartes WalletApple et GoogleHTTPS
Parcours clientscan, jeu, lotBack-office commerçantConsole d’administrationServeur · DockerAPI REST Laravelpar domaine métierAccès par paliermenu, routeur et APIBase relationnellepaliers modifiablesCache et filesCatalogue des fonctionnalitésDéploiement automatiqueGitHub Actions, DockerServices tiersStripeabonnementsService d’IAréponses aux avisAvis GoogleGoogle PlacesNotificationsOneSignalCartes WalletApple et Google
Schéma d’architecture de la plateforme en plan cyanotype : parcours client, back-office et console reliés à une API Laravel, accès par palier, base et files, services tiers
L’exécution · Ce que j’ai réalisé
Les abonnements : facturation par établissement avec Laravel Cashier et Stripe, paiement en ligne, webhooks signés, relances de paiement sur un calendrier personnalisé puis suspension, paiement manuel réservé à l’administrateur.
Les paliers : stockés en base et modifiables depuis la console, avec un catalogue de fonctionnalités centralisé dans la configuration.
Le contrôle d’accès par fonctionnalité : vérifié à trois niveaux (menu, routeur Vue, routes de l’API), avec une invitation à souscrire quand aucun abonnement n’est actif.
Les rôles : un membre d’équipe ne voit que le tableau de bord et la validation des récompenses, sur les mêmes trois niveaux.
La reprise d’historique : import CSV tolérant aux en-têtes en français ou en anglais, avec dédoublonnage des contacts.
La réputation : suivi des avis Google, architecture ouverte aux autres plateformes, réponses générées par IA avec plusieurs fournisseurs au choix, publication semi-automatique.
Les modules marchands : base clients, fidélité, campagnes e-mail, SMS et notifications, statistiques de conversion, packs préconfigurés par secteur, éditeur de visuels, cartes Apple et Google Wallet prêtes à activer.
L’infrastructure : images Docker déployées automatiquement sur le serveur du client, intégration continue GitHub Actions sur chaque modification (style de code, tests, build du front).
Les tests : suites PHPUnit sur les parties critiques (accès par palier, administration des paliers, droits des membres d’équipe, import, relances de paiement).
Le matériel · Stack technique
Front : Vue 3, TypeScript, Pinia, routes typées, interface en français et en anglais.
Back : Laravel, architecture par domaine métier, API REST versionnée, Laravel Cashier, gestion des rôles et permissions.
Données : base relationnelle, cache et files d’attente.
Services : Stripe, OneSignal, Google Places, Apple et Google Wallet.
Livraison : Docker, GitHub Actions, déploiement automatique, environnements séparés de développement, préproduction et production.
Incident n°1 : des paliers d’abonnement qui n’existent pas encore
Imprévu. Le client doit pouvoir créer un nouveau palier à tout moment, avec son prix et ses fonctionnalités, et voir les bons écrans se débloquer sans redéploiement.
Parade. La liste des fonctionnalités vit dans la configuration, en un seul endroit. Les paliers vivent en base et y font référence. Le contrôle d’accès s’applique sur les trois niveaux par un même middleware. Un test le prouve : un palier créé après coup débloque bien ses fonctionnalités.
Ce que j’en retiens. Séparer la configuration (ce qui existe) de la donnée métier (ce qui est vendu) rend la facturation évolutive.
Incident n°2 : facturer l’établissement, pas l’utilisateur
Imprévu. Un même compte gère plusieurs établissements, et chacun a son abonnement et son propre cycle de paiement. Par défaut, Laravel Cashier facture l’utilisateur.
Parade. La capacité de facturation est portée par l’entité Établissement. Les relances de paiement sont codées à part, avec leur propre calendrier et une suspension automatique, et un paiement manuel couvre les règlements hors ligne.
Ce que j’en retiens. Cashier est souple sur l’entité facturée, mais la logique de relance propre au métier doit être écrite et testée séparément.
Incident n°3 : une permission qui n’était qu’un masque
Imprévu. Un membre d’équipe avait accès à tout le back-office alors qu’il ne devait que consulter le tableau de bord et valider des récompenses.
Parade. Une permission dédiée, vérifiée en même temps sur le menu, sur le routeur Vue et sur les routes de l’API, avec une exception explicite pour l’administrateur.
Ce que j’en retiens. Une permission n’est fiable que si elle est vérifiée côté serveur. Côté client, elle ne fait que masquer.
Incident n°4 : des fichiers CSV tels que les commerçants les produisent
Imprévu. Les historiques à importer mélangeaient en-têtes français et anglais, accents, majuscules et formats de date. Une fonction de lecture de date levait une exception au lieu de signaler un échec.
Parade. Résolution des en-têtes par alias normalisés, dédoublonnage des contacts, création en inactif des éléments manquants, et chaque tentative de lecture de date protégée.
Ce que j’en retiens. Un import destiné à des commerçants doit être défensif par défaut. Personne ne nettoiera son fichier avant de l’envoyer.
Le bilan · Résultats
La nouvelle plateforme est livrée en préproduction, avec l’ensemble des modules prévus : fidélité et marketing, réputation, statistiques, packs sectoriels, éditeur de visuels, cartes Wallet, abonnements et reprise de données.
Le parcours de souscription Stripe est validé de bout en bout en mode test, synchronisation par webhook comprise.
Le modèle par abonnement est opérationnel : paliers configurables, accès par fonctionnalité, facturation par établissement.
Mise en production imminente. Les premiers chiffres d’usage viendront après quelques semaines d’exploitation.
