GOA B2B

J’ai conçu et développé la plateforme sur laquelle ces clients commandent désormais, et je l’ai connectée à Easybeer, l’ERP qui fait déjà tourner l’activité de GOA : une commande passée sur le web devient une commande dans l’ERP, sans aucune étape manuelle entre les deux.

Les commandes arrivaient auparavant par un Jotform. Quelqu’un chez GOA les ressaisissait ensuite une à une dans Easybeer, à la main, entre 100 et 150 fois par mois. Le formulaire ne savait rien de la personne qui commandait : ni prix propres à chaque client, ni remises, ni minimum de commande, ni contraintes de transporteur. Tout était vérifié après coup, et les erreurs étaient repérées tard.

Le brief n’était pas de reconstruire cet ERP, mais d’arrêter de le dupliquer. La plateforme lit les données d’Easybeer et n’y réécrit que les commandes : GOA garde ainsi un seul endroit pour gérer produits, prix et clients, et ses clients profitent d’une expérience de commande qui connaît déjà leurs conditions.

01 Synchronisation : une tâche côté serveur récupère le catalogue, les prix par client, les remises et les réglages de livraison depuis Easybeer, et les met en cache dans Firestore.

02 Commande : les clients professionnels parcourent leur propre catalogue à leurs propres prix et composent un panier qui connaît déjà leurs remises, leur minimum et les règles de transporteur.

03 Réécriture : la validation du panier crée la commande directement dans Easybeer. Rien n’est ressaisi, et un nouvel enregistrement met à jour la même commande au lieu de la dupliquer.

Easybeer reste la source de vérité : la plateforme lit catalogue, prix, remises, réglages clients et factures depuis l’ERP, et n’y réécrit qu’une seule chose : la commande. Aucune donnée métier n’est dupliquée, GOA continue donc de gérer ses produits et ses tarifs là où elle l’a toujours fait.

Chaque prix est personnel : les prix ne sont jamais uniformes. La même bouteille coûte un montant différent selon le type de client, avec des tarifs personnalisés par client et quatre niveaux de remises superposés. Chaque prix affiché est calculé pour le client connecté, jamais un prix catalogue par défaut.

Un catalogue sur adhésion : l’ERP contient des dizaines de produits référencés, mais seuls quelques-uns doivent être commandables. Une couche de personnalisation permet à GOA d’activer ou masquer un produit, de réécrire les libellés techniques, d’ajouter une photo et de signaler une rupture de stock. Les nouveaux produits restent masqués par défaut.

Les règles métier vivent dans le panier : les contraintes de transporteur sont appliquées pendant la commande. Les clients livrés par La Poste commandent par multiples de 3 pour le 35 cl et de 2 pour le 1 L afin que les caisses restent homogènes, et le montant minimum de commande est lu dans la fiche de chaque client.

Modifiable, pas recommandée : une commande reste modifiable jusqu’à ce que l’ERP la marque comme livrée. Un nouvel enregistrement met à jour la même commande au lieu d’en créer une seconde, ce qui supprime l’ancien contournement « cette commande annule la précédente ».

Mobile d’abord : environ 90 % des commandes sont passées depuis un téléphone, souvent dans un bar ou une arrière-salle. Le parcours de commande est pensé d’abord pour ce contexte ; l’administration suppose un écran plus grand.

Front-end : Vue 3, Vite et TypeScript, avec shadcn-vue (Reka UI + Tailwind CSS v4) comme design system unique pour la boutique client et la console d’administration. TanStack Query pour les lectures, TanStack Table pour les grilles d’administration, Zod pour la validation.

Back-end : un serveur Hono qui fait office de seule porte d’entrée vers Easybeer : les identifiants Basic Auth restent côté serveur et n’atteignent jamais le bundle du navigateur, aux côtés des endpoints d’administration, des écritures de commandes et de la tâche de synchronisation planifiée.

Authentification & données : Firebase Auth, sans aucune inscription publique : un compte n’existe que pour un client que GOA facture déjà, invité depuis sa fiche dans l’ERP. Firestore conserve l’état propre à la plateforme, la part que l’ERP ne gère pas, et Firebase Storage les photos de produits.

Vivre avec une API limitée : l’API de l’ERP limite agressivement le débit, et réessayer pendant une période de blocage ne fait qu’aggraver les choses. Une file d’attente sortante unique cadence chaque appel, un disjoncteur échoue localement plutôt que de marteler l’API pendant un blocage, et le modèle de lecture en cache fait que le trafic des clients n’atteint jamais l’ERP : seules les écritures de commandes le font.