Mnadhem

Ces commerces tournent avec un tableur, un carnet et un groupe de discussion. Le stock et la caisse ne sont rapprochés qu'en fin de semaine, trop tard pour agir. Les outils importés n'échouent pas à cause de la langue : leur modèle de données suppose le paiement par carte, des fournisseurs qui facturent et un canal de vente unique.

Le registre de trésorerie est la source de vérité. Chaque vente, règlement fournisseur, retour, frais de livraison ou retrait du gérant est une écriture, et le stock est calculé à partir de ces écritures : les chiffres se rapprochent d'eux-mêmes. La rapidité de saisie passe en premier : enregistrer une vente tient sur un écran, car personne n'utilisera un outil plus lent que son carnet.

• Registre de trésorerie en partie double, à partir duquel le stock est calculé
• Ventes multicanales : boutique, messages sur les réseaux sociaux, partenaires de livraison
• Comptes fournisseurs acceptant les règlements partiels, informels et dans le désordre
• Accès par rôle pour le gérant, le responsable de boutique et le magasinier

Next.js App Router avec des server components pour toutes les pages qui lisent des données, si bien que les listes n'envoient presque aucun JavaScript au navigateur. NestJS fait tourner un module par domaine (registre, stock, catalogue, identité) sur PostgreSQL. Les écritures du registre ne sont jamais modifiées : une erreur se corrige par une écriture inverse, et l'historique de chaque chiffre reste traçable.