Caisse tactile et suivi d'activité à distance pour une librairie

Le contexte

Al-Habib est une TPE de ma ville : une librairie de livres religieux, complétée par des accessoires de mosquée — parfums, vêtements, et autres articles. La boutique est tenue au quotidien par un vendeur, le patron n'y étant pas en permanence.

C'est une petite structure familiale, à l'échelle exacte pour laquelle ce type d'outil a du sens : assez d'activité pour que l'absence de suivi coûte réellement, pas assez de moyens pour envisager une caisse du marché.

Le problème à résoudre

Rien n'était digitalisé. Le commerçant disposait d'un terminal SumUp relié à son téléphone pour encaisser les paiements par carte, et d'un suivi des ventes intégralement sur papier pour tout le reste.

Le vrai point de douleur n'était pas l'encaissement — il fonctionnait. C'était l'absence de visibilité du patron sur sa propre activité.

Pour savoir comment se passait la journée, il n'avait que deux options : être physiquement dans la boutique, ou appeler son vendeur pour lui demander. Deux options coûteuses, et surtout deux options qui ne laissent aucune trace exploitable. Ce qui s'était vendu la semaine précédente restait, dans les faits, inconnaissable.

Les conséquences en cascade :

• aucun recul sur les chiffres : pas de chiffre d'affaires consolidé, pas de comparaison d'un mois sur l'autre ;
• aucune connaissance de ce qui se vend : impossible de savoir quels articles tournent et lesquels dorment, donc impossible d'acheter juste ;
• aucune visibilité sur le stock, et donc des ruptures découvertes au moment où un client demande le produit.

À cela s'ajoutait la contrainte déterminante : un budget de TPE. Les caisses du marché, avec leur abonnement mensuel et leurs fonctionnalités calibrées pour des enseignes bien plus grandes, étaient hors de portée et surdimensionnées.

Ce que j'ai mis en place

Un POS délibérément petit, distribué en PWA. C'est le point important de cette mission : la valeur n'était pas dans la richesse fonctionnelle, elle était dans le fait qu'il soit assez simple pour être réellement utilisé au quotidien, et assez léger pour rentrer dans son budget.

Deux usages, deux appareils

La PWA donne l'équivalent d'une application installée, sans passer par un store ni par une procédure de déploiement. Elle est pensée pour deux contextes d'usage distincts :

• le vendeur, sur mobile — en boutique, debout, entre deux clients. L'interface de saisie doit être rapide et tenir dans une main.
• le patron, sur iPad — pour consulter l'activité. Un écran plus large permet d'afficher des chiffres et des tendances sans compromis.

C'est ce découpage qui règle le problème initial : le patron n'a plus à être là ni à appeler, l'information vient à lui.

La saisie des ventes

Le cœur de l'outil, côté vendeur. Pour chaque vente :

• les articles ;
• les quantités ;
• les prix ;
• le mode de paiement, carte bancaire ou espèces.

La distinction carte/espèces n'est pas cosmétique : c'est elle qui permet de rapprocher les encaissements SumUp du reste et de savoir ce qui passe réellement en liquide.

Le parti pris est le même partout dans l'interface vendeur : le moins de gestes possible entre l'arrivée du client à la caisse et la vente enregistrée. C'est une contrainte non négociable sur ce type d'outil — un vendeur debout, entre deux clients, n'utilisera jamais durablement une saisie qui lui prend plus de temps que de noter la vente sur un carnet.

La gestion de catalogue

Réduite à quatre informations, volontairement : le produit, sa référence, sa catégorie, son stock initial.

C'est un choix qui va à l'encontre du réflexe habituel d'un développeur, qui aurait tendance à vouloir tout modéliser dès le départ — fournisseurs, marges, variantes. Pour une TPE, chaque champ en plus est une friction au moment de la saisie initiale, qui est presque toujours le vrai point de blocage sur ce type de projet : un catalogue trop lourd à remplir ne sera jamais rempli, et l'outil finit par ne plus refléter la réalité.

Le tableau de bord et les alertes

Un suivi volontairement minimal, réduit à ce qui répond directement au problème initial : le chiffre d'affaires global et une alerte sur les produits dont le stock passe sous dix unités. Pas de tableau de bord chargé d'indicateurs secondaires — c'est le même principe que pour le catalogue : un écran que le patron comprend d'un coup d'œil, depuis un iPad, entre deux autres tâches.

Les choix techniques

Nuxt avec Nuxt UI pour l'interface, Spring Boot et PostgreSQL pour le back-end.

Le choix de Spring Boot n'est pas dicté par la taille du projet, mais par la robustesse du framework et l'aisance que j'y ai acquise au fil de mon parcours : structurer proprement un domaine métier, même simple, avec Spring Boot ne coûte pas plus cher en temps qu'un framework plus léger, et le résultat est un back-end sur lequel il est facile de revenir ajouter une fonctionnalité sans tout reprendre.

Nuxt UI, de son côté, est un choix pragmatique plutôt qu'un compromis par défaut : sur un budget de TPE, un habillage entièrement sur mesure aurait consommé du temps de développement sans rien apporter à l'usage réel de l'outil. Nuxt UI donne une interface cohérente et soignée dès le départ, ce qui libère le temps pour ce qui compte vraiment ici — la rapidité de saisie et la lisibilité du tableau de bord.

Les résultats

Le projet a été livré début 2026 : il est encore trop tôt pour des chiffres consolidés sur plusieurs mois. Ce qui est acquis dès la mise en service, en revanche, c'est le changement de nature du suivi. Le suivi papier a disparu, remplacé par une saisie systématique à chaque vente. Le patron dispose désormais d'un chiffre d'affaires consultable à tout moment, sans dépendre de sa présence ni de celle de son vendeur au bout du fil — ce qui, avant l'outil, n'existait tout simplement pas.

Ce que j'en retiens

Ce projet illustre bien une chose que je vérifie à chaque mission pour une TPE : le besoin exprimé n'est presque jamais le vrai besoin. Al-Habib parlait de « suivre ses ventes », mais le sujet réel était de ne plus dépendre de sa présence physique pour savoir ce qui se passait dans sa propre boutique.

Une TPE sans budget n'a pas besoin d'une version allégée d'un logiciel pensé pour des enseignes plus grandes. Elle a besoin d'un outil conçu directement à son échelle, où chaque écran et chaque champ ont été pensés pour être utilisés tous les jours par une seule personne, sans formation ni temps d'adaptation. C'est un exercice différent de développer « en plus petit » : il s'agit de choisir ce qu'on retire, pas ce qu'on simplifie.