Étude de cas full-stack
OneGate
Le guichet unique du sourcing et du transport B2B — les clients à l'étranger déposent leurs demandes, les agents chiffrent fournisseurs et fret, et les commandes avancent de l'échantillon à la livraison en gros.
- Rôle
- Développeur Full-Stack — en solo
- Durée
- 6 semaines — en cours
- Année
- 2026
- Stack
- React · TypeScript · Express.js · MongoDB · Redis
- En ligne
- onegate.llc
01 / Le problème
Une agence d'import qui tournait aux discussions et tableurs.
Les clients qui voulaient faire sourcer des marchandises à l'étranger ou expédier du fret traitaient avec l'agence à travers des discussions éparpillées : le personnel chiffrait fournisseurs, échantillons et transport à la main, les paiements arrivaient sous forme de preuves de virement dans des fils de messages, et personne n'avait une vue unique de l'état d'une commande entre les phases de sourcing, d'échantillon et de gros.
Utilisateurs cibles
Importateurs B2B et vendeurs e-commerce — arabophones et anglophones — ainsi que les agents de sourcing, agents de transport, managers et admins de l'agence.
02 / La solution
Une plateforme, un seul guichet.
Une plateforme cloisonnée par rôles où les clients déposent leurs demandes de sourcing ou de transport et les suivent à travers le chiffrage, les échantillons, la tarification en gros et la livraison — avec des preuves de paiement téléversées, vérifiées par les admins et facturées en PDF. Cinq flux de commande distincts partagent un même moteur de cycle de vie sous garde, et chaque événement métier notifie les bons rôles en temps réel.
Pourquoi cette stack
- MongoDB — un document de commande imbriqué et polymorphe par flux
- Redis — file d'e-mails, limites de débit partagées et pub/sub SSE
- Même origine via Caddy — cookies de session first-party, zéro CORS
- Cluster Node — service multi-processus sur un seul VPS
03 / Fonctionnalités
Ce que la plateforme fait.
Auth & six rôles
Sessions, OAuth Google et limites anti-force brute sur six rôles cloisonnés
Commandes multi-flux
Cinq flux de commande via des machines à états de phase et de statut
Paiements manuels
Preuves téléversées et vérifiées par les admins, factures PDF côté client
Notifications temps réel
Pub/sub Redis diffusé vers des flux SSE sur chaque worker
Six tableaux de bord
Plus de 50 pages routées avec analytics, anglais/arabe et RTL complet
Téléversements directs vers R2
URL PUT présignées avec listes blanches strictes de types de contenu
04 / Défis techniques
Les parties difficiles — et comment elles ont cédé.
Cinq flux de commande, une machine à états
La même commande peut être un parcours complet sourcing → échantillon → gros, un achat direct en gros, ou un simple transport de fret — et les clients, deux types d'agents et les admins la modifient tous. Une seule transition illégale corrompt de vrais flux d'argent.
Comment je l'ai résolu
Un document unique porte flowType, activePhase et des énumérations de statut par phase ; chaque transition est une fonction de service dédiée qui revalide propriété, flux, phase et statut avant d'écrire. Les devis confirmés matérialisent les tarifs unitaires dans le sous-document « gros », si bien que la tarification fixe emprunte la machinerie de paiement existante, et les numéros de commande lisibles sont attribués sans concurrence via un upsert atomique de compteur.
Temps réel à travers un cluster de processus
L'API tourne sur jusqu'à quatre workers forkés plus un worker e-mail séparé. Une connexion SSE vit sur exactement un processus, mais l'événement qui doit l'atteindre peut naître sur n'importe quel autre.
Comment je l'ai résolu
Les notifications sont persistées dans MongoDB, puis publiées via le pub/sub Redis ; chaque worker garde une connexion abonnée dédiée et son propre registre de flux ouverts, et ne relaie que les événements correspondants. Des commentaires de heartbeat empêchent les proxies de tuer les flux inactifs, et la notification est en fire-and-forget : une panne de Redis ne peut jamais casser l'action métier.
Rester correct sous montée en charge horizontale
Forker des workers casse silencieusement tout ce qui a un état par processus — compteurs de limitation de débit, détection de l'IP client derrière le proxy, et répartition équitable du travail entrant.
Comment je l'ai résolu
Les limites de débit stockent leurs compteurs dans Redis pour que le plafond tienne sur tous les workers — avec dégradation ouverte si Redis tombe ; trust proxy est fixé à exactement un saut. Les commandes entrantes sont auto-assignées à l'agent le moins chargé via une agrégation avec égalités mélangées, ce qui redistribue aussi le travail quand un agent part.
05 / Architecture
Comment le système s'assemble.
REACT 19 SPA
six panneaux de rôles · PWA · EN/AR RTL
EXPRESS 5 API
better-auth · Zod · cluster Node
MONGODB
commandes · paiements · notifications
CLOUDFLARE R2
téléversements directs présignés
REDIS
file · limites de débit · pub/sub
SMTP + BULLMQ
worker e-mail avec relances
Services externes
06 / Captures d'écran
Le produit, de près.
07 / Résultats
Ce que ça a changé concrètement.
Tout le flux de courtage de l'agence — chiffrage, échantillons, tarification en gros, vérification des paiements — passe désormais par une seule connexion au lieu de tableurs et de fils de discussion. Six rôles voient exactement leur file, chaque changement de statut notifie en temps réel les personnes concernées, et la plateforme se déploie en continu via un pipeline CI qui exécute une suite end-to-end full-stack avant chaque mise en production.
08 / Stack technique
Construit avec.
Frameworks
- React 19
- Express 5
- Node.js
- Vite
Bibliothèques
- better-auth
- React Query
- BullMQ
- Zod
- Tailwind CSS
- Recharts
Infrastructure
- MongoDB
- Redis
- Docker
- Caddy
- Cloudflare R2
- GitHub Actions CI/CD
09 / Ma contribution
Ce que j'ai construit, précisément.
- Développé le moteur de cycle de vie des commandes : cinq types de flux avec machines à états phase/statut, gardes de transition par rôle, matérialisation des devis et numérotation atomique des commandes.
- Développé des notifications temps réel sûres en cluster : pub/sub Redis vers des registres SSE par worker avec heartbeats, persistance élaguée par TTL et l'interface de la cloche de notifications.
- Mis en place l'infrastructure de production de bout en bout : point d'entrée du cluster Node avec arrêt gracieux, overlays Docker Compose, TLS same-origin via Caddy, et le pipeline CI → registre → déploiement SSH conditionné à une suite e2e Playwright.
- Développé six panneaux frontend cloisonnés par rôle (~50 pages routées) avec i18n anglais/arabe RTL, packaging PWA, graphiques d'analytics et devis et factures PDF côté client.
- Développé l'auto-assignation des agents avec équilibrage de charge : sélection du moins chargé par agrégation, mélange des égalités et redistribution au départ d'un agent ; configuré et durci la couche better-auth (liaison de comptes, limites par route).