Fidélisation et récompenses
Une plateforme de commerce fidélité, de l’ERP à la vitrine
Trois chantiers coordonnés à titre d’équipe d’ingénierie intégrée : un ERP Java en production qui a continué de livrer, une vitrine découplée bâtie de zéro, et une trousse de migration qui a déplacé les données entre les deux.
Client
Une entreprise nord-américaine de fidélisation corporative et d’exécution de récompenses
5 semaines
jusqu’à la préparation au lancement
Le défi
Ce qui bloquait
Le client exploite des programmes d’avantages et de récompenses corporatifs — un ERP détenant le catalogue, les commandes et l’exécution, et le besoin de placer des vitrines aux couleurs de la marque devant les clients finaux.
L’ERP était ancien et critique pour l’entreprise, la vitrine n’existait pas, et les données devaient circuler entre les deux sans une journée d’interruption.
La solution
Ce que nous avons bâti
Trois chantiers coordonnés à titre d’équipe d’ingénierie intégrée. Du côté de l’ERP, développement continu d’un système Java et Spring Boot en production, livré par Jenkins vers AWS, avec balayage des secrets dans le pipeline et règles explicites de sécurité pour la base de données de production.
La vitrine est une plateforme de commerce découplée bâtie de zéro — une couche d’orchestration mince et rigoureuse au-dessus de trois systèmes qui ne nous appartiennent pas (le catalogue et l’API d’exécution du client, Stripe pour les paiements et les taxes, et un fournisseur de courriels transactionnels) avec PostgreSQL comme système de référence réconciliant l’état des paiements et l’état de l’exécution pour chaque commande.
L’ingénierie est délibérément conservatrice là où ça compte. Une règle de linter interdit au code du domaine d’importer le moindre cadriciel, et l’intégration continue fouille le paquet produit pour prouver qu’aucun ne s’y est glissé. Il n’y a pas de courtier de messages : la colonne de statut de commande est la file, réclamée par FOR UPDATE SKIP LOCKED, ce qui retire un pan entier d’infrastructure de la surface de défaillance.
La migration s’est déroulée au moyen d’une trousse conçue sur mesure de scripts de convergence, de réconciliation et de vérification exécutés contre le schéma en production, avec un recensement complet de ce qui a été déplacé.
Technologies clés
- Vitrine
- Next.js 16, React 19, TypeScript, Tailwind 4, next-intl (EN/FR)
- Données
- Prisma 7, PostgreSQL 18, Redis, travailleur Postgres-comme-file
- Intégrations
- Paiements et taxes Stripe, NetSuite, API catalogue du client
- ERP
- Java/Spring Boot, PHP/CodeIgniter, Jenkins, AWS, gitleaks
- Qualité
- Biome, Vitest, Playwright incluant des tests visuels de conformité au design
Retombées et résultats
Préparation au lancement en cinq semaines
30 migrations de schéma couvrant recommandations, droits, taxes, rôles d’administration, audit et agrégats de rapports.
Des frontières d’architecture imposées par la machine
La couche du domaine ne peut pas dériver vers un couplage au cadriciel, parce que l’intégration continue refuse la fusion.
De l’infrastructure délibérément retirée
Aucun courtier à exploiter, à surveiller ou à voir défaillir.
Un ERP en production qui a continué de livrer
Pendant que son interface de remplacement était bâtie à côté.
Commencez ici
Commencez par un problème, pas par un cahier des charges.
Dites-nous ce qui est lent, ce qui est manuel, ce qui est bloqué, ou ce que plus personne ne comprend. Nous vous dirons honnêtement si cela vaut la peine d’être bâti.