Étude de cas
Une application web de gestion de stock et de ventes pour un petit commerce : catalogue, réceptions fournisseurs, ventes, retours clients et inventaires, avec les montants en FCFA.
Sur la page de connexion, le bouton « Explorer la démo » ouvre l'application en lecture seule. L'API est hébergée sur un plan gratuit : le premier chargement peut prendre jusqu'à une minute.
Un petit commerce a besoin de savoir, à tout moment, ce qu'il a en stock, ce que lui coûte chaque produit et ce qui se vend. Le piège classique est un stock affiché qui ne correspond plus à la réalité.
Mon objectif : une application où le stock affiché est toujours égal à la somme des mouvements enregistrés, même avec des unités multiples comme la bouteille, le carton de 12 ou le sac de 25 kg.
Chaque opération (réception, vente, retour, ajustement) écrit ses lignes et ses mouvements dans une seule transaction PostgreSQL, puis met à jour le stock courant et le coût moyen. Le stock affiché correspond donc toujours à la somme des mouvements.
Chaque ligne stocke la quantité saisie et son facteur. La quantité en unité de base est une colonne calculée par PostgreSQL : impossible de la faire diverger de la saisie.
Le rôle DEMO est contenu dans le jeton, et un seul middleware refuse toute requête d'écriture (403 DEMO_READ_ONLY). Masquer des boutons dans l'interface ne suffirait pas à protéger la démo.
Le navigateur ne parle qu'à Vercel, qui réécrit /api/* vers l'API hébergée sur Render. Moins de configuration, moins de surface d'erreur.
Suite