TruckParts

01

Ce qu'il fallait, et ce que j'ai construit

Un vendeur de pièces de camion a besoin de plus qu'une liste de produits. Les clients doivent savoir qu'une pièce va sur leur camion avant d'acheter. Les paiements doivent être réels, pas un faux bouton. Et si deux personnes achètent la dernière pièce en même temps, une seule doit l'avoir. Un modèle de boutique basique ne gère rien de tout ça.

01 · Compatibilité

ProblèmeLes clients doivent savoir qu'une pièce va sur leur camion avant d'acheter.

Construit« Find My Part » : on choisit le constructeur, le modèle et l'année du camion, et seules les pièces compatibles s'affichent.

Pièces et véhicules sont reliés par une table de compatibilité (une ligne par couple pièce–véhicule)

02 · Paiement

ProblèmeUn bouton « Payé » que le navigateur peut simuler n'est pas un paiement.

ConstruitUne commande n'est marquée payée que lorsque Notch Pay le confirme : Mobile Money, carte, ou espèces au retrait.

Webhooks vérifiés par signature HMAC-SHA256 · un webhook en retard déclenche une vérification directe du statut

03 · Stock

ProblèmeDeux clients veulent acheter la dernière pièce à la même seconde.

ConstruitLe stock est réservé en une seule étape : un seul paiement l'obtient, l'autre est prévenu qu'elle n'est plus disponible.

Un seul UPDATE … WHERE quantity >= n conditionnel dans une transaction

02

Comment c'est construit

J'ai construit toute la boutique, frontend et backend. La vitrine est en Next.js. Elle a une recherche « Find My Part », un panier et deux façons de payer : en ligne avec Notch Pay, ou en espèces au retrait. Il y a aussi le suivi des commandes, les codes promo et les avis. Derrière, une API NestJS gère les produits, les commandes et les paiements pour l'administration.

Frontend

Next.js + TypeScript + TailwindUn seul code pour la boutique et l'administration. Des server components là où ils aident, et pas d'application séparée à héberger.

Backend

NestJS + TypeScriptUn module par domaine (auth, commandes, paiements, images...). Plus facile à tester et à maintenir qu'une grosse application Express.

Base de données

PostgreSQL + PrismaLes commandes, le stock et les paiements doivent rester justes. Une base relationnelle est le bon outil pour ça.

Stockage des fichiers

MinIO locally, Backblaze B2 in productionLes deux utilisent le protocole Amazon S3, donc le même code marche en local (sans compte cloud) et en production. Changer ne demande que des réglages.

Authentification

JWT + httpOnly refresh cookieLe jeton de courte durée reste en mémoire, où un script injecté ne peut pas le lire. La session plus longue est dans un cookie que JavaScript ne peut pas toucher.

Paiements

Notch PayPage de paiement hébergée et webhooks, avec le Mobile Money pour l'Afrique centrale.

03

Ce qui était difficile

• Éviter de vendre plus que le stock. Lire le stock puis le modifier peut créer un conflit, donc le paiement lance un seul UPDATE ... WHERE quantity >= demandé dans une transaction.
• Les webhooks n'arrivent pas toujours à temps. Quand une commande reste en attente, le backend vérifie le statut du paiement auprès de l'API Notch Pay au lieu d'attendre.
• Ajouter l'accessibilité après la première version. J'ai lancé un audit axe-core et corrigé ce qu'il a trouvé : repères manquants, navigation sans étiquette et contrastes trop faibles.
• Rendre l'administration utilisable sur téléphone. J'ai refait chaque liste en cartes sur petit écran, au lieu d'un tableau qui défile sur le côté.

04

Résultat

Elle est en ligne comme démo sur Vercel. Avec les comptes de test, on peut faire tout le parcours : parcourir, vérifier qu'une pièce va, ajouter au panier, payer en ligne ou au retrait, confirmer le paiement, suivre la commande et la traiter côté administration. Les paiements passent par le mode test de Notch Pay, donc aucun vrai argent n'est débité.

05

Écrans

9 écrans · touchez pour agrandir