Logiciel de caisse épicerie : le cas KiranaSetu
Découvrez KiranaSetu, une caisse open source pour épicerie : facturation, stock, commandes à retirer et limites à vérifier avant tout déploiement.
KiranaSetu : une caisse open source pensée pour les commerces de proximité
Dans une petite épicerie, le problème n'est pas d'abord le manque d'outils numériques. C'est le timing : un client attend pendant que le commerçant vérifie le stock, une commande s'ajoute à la file, un paiement reste à rapprocher, ou une vente est notée trop vite sur un carnet. Une bonne caisse doit d'abord réduire ces frictions - sans exiger une connexion permanente ni un abonnement dont le coût serait difficile à amortir.
KiranaSetu Pro est un prototype open source pour les magasins de quartier indiens, les kirana stores. Il combine caisse, inventaire, commandes à retirer, livraison locale, suivi du crédit client, et quelques fonctions d'IA. L'intérêt du projet n'est pas seulement dans la liste : il force aussi à choisir ce qu'on automatise, ce qu'on garde simple, et ce qu'on fait sans exposer inutilement les données. Voici ce qu'il propose, ce que sa conception permet vraiment, et les points à vérifier avant d'envisager un usage sérieux - en Inde comme, avec prudence, dans un commerce européen.
KiranaSetu répond-il à un vrai problème de caisse ?
Le projet s'appuie sur un contexte assez concret : beaucoup de petites transactions, des marges serrées, et des clients qui veulent aller vite. Dans ce cadre, une caisse qui impose une connexion permanente, ou qui prélève une commission à chaque vente, devient vite un coût opérationnel. Le carnet papier reste simple à manier, mais il compliquera le suivi des prix, des stocks et des sommes dues.
KiranaSetu regroupe plusieurs opérations dans une seule interface : rechercher un produit, vérifier sa disponibilité, créer une facture, préparer une commande et consulter le compte client. L'idée est pragmatique : limiter les allers-retours entre un carnet, un outil de messagerie et une caisse séparée. Dans un magasin où les commandes passent par WhatsApp, cette continuité peut compter autant qu'un tableau de bord « complet ».
Côté technique, le projet est présenté comme une application de gestion pouvant fonctionner hors ligne, construite en JavaScript modulaire avec Vite. Il y a une interface commerçant et un portail de précommande client, avec navigation possible entre les deux. Mais la démonstration décrite dans la publication reste une démonstration : une application exécutée localement n'est pas, à elle seule, la preuve d'un service stable en production.
Le développeur mentionne un tarif potentiel de 299 à 499 roupies par mois, ou des frais d'installation ponctuels. Il cite aussi le retour d'un commerçant pilote, prêt à payer 350 roupies mensuelles pour des rappels de crédit et des retraits préparés à l'avance. C'est encourageant, mais ça ne suffit pas pour conclure à un marché : un témoignage isolé ne dit rien sur le taux d'adoption, le coût réel du support, ni la capacité à fidéliser.
Pour un lecteur français, il faut enfin distinguer le modèle du produit de son contexte réglementaire. Les roupies, l'UPI et les règles de GST sont propres à l'Inde. En France, une épicerie devra plutôt examiner ses obligations de caisse et de facturation, ainsi que ses moyens de paiement locaux. Au final, le projet ressemble davantage à un bon cas d'étude sur l'organisation d'un commerce de proximité qu'à une caisse « prête à copier-coller » en Europe.
Les fonctions qui changent le travail au comptoir
On juge une caisse moins au nombre d'écrans qu'aux secondes gagnées et aux erreurs qu'elle évite - dans le bruit réel du comptoir, pas sur des slides.
Caisse, tarifs et disponibilité du stock
Le point de vente permet de rechercher des produits, y compris avec des termes anglais ou en devanagari, et d'afficher un indicateur de stock. Les articles épuisés sont désactivés pour éviter de les ajouter au panier par erreur. Le commerçant peut ensuite facturer à partir de prix enregistrés, calculer des taxes selon la configuration, et générer un reçu thermique de 80 mm ou une facture A4.
Ce mécanisme limite les erreurs de saisie, mais il ne les efface pas automatiquement. La fiabilité dépend du catalogue, de la fréquence de mise à jour des prix, et de la manière dont les retours, remises et corrections sont gérés. Un stock « disponible » n'aide pas si, en pratique, ventes, livraisons et ajustements ne le mettent pas à jour de façon cohérente.
Paiement UPI et commandes à retirer
Pour les paiements, l'application génère un QR code à partir d'un lien UPI qui inclut le montant, l'identifiant du bénéficiaire et une référence de facture. Le client peut le scanner avec une application compatible. Le navigateur peut aussi jouer une séquence sonore et prononcer un message en hindi après une action de l'application.
Le point important : il faut séparer l'affichage d'une demande de paiement de la confirmation qu'un paiement a été reçu. Un QR code généré ne garantit pas que la transaction a abouti. Et un son émis par l'application n'est pas une preuve bancaire : il peut simplement indiquer qu'une action a été déclenchée sans vérifier le statut. Pour valider un paiement, il faut un rapprochement fiable avec un prestataire ou un mécanisme indépendant. Cette distinction devient critique dès qu'on s'en sert pour clôturer une vente.
Le module de précommande permet au client de choisir des produits et un créneau de retrait, puis d'obtenir un numéro de jeton. Le commerçant dispose ensuite d'une liste de préparation pour constituer le sac avant l'arrivée du client. Ce n'est pas révolutionnaire, mais sur les périodes de pointe, ça peut vraiment réduire la chasse aux articles « au dernier moment ».
Le même principe se retrouve pour la livraison locale : adresse, repère, créneau et frais calculés selon un seuil configuré. Le suivi est pensé autour de WhatsApp. Là encore, avant de passer à grande échelle, il faut vérifier les modalités d'envoi, le consentement des clients, et la robustesse du processus.
Crédit client et liste de courses assistée par IA
Le registre numérique khata suit les sommes dues et les remboursements. Une fonction Gemini peut proposer plusieurs formulations de rappel - du ton respectueux à un message plus direct - puis aider à les partager sur WhatsApp. On est sur un usage d'IA assez « ciblé » : l'outil ne remplace pas la comptabilité, il aide surtout à écrire un message délicat sans que le commerçant doive repartir de zéro.
Une autre fonction, la « Smart Parchi », prend une liste de courses en langage courant et tente de la rapprocher du catalogue. Elle peut interpréter des expressions locales de quantité, proposer des produits, et signaler ceux qui ne sont pas disponibles. Le but est de préremplir le panier, que le commerçant doit vérifier avant de facturer.
À mes yeux, c'est une meilleure place pour l'IA qu'un simple chatbot « décoratif » : on automatise une partie répétitive, tout en gardant la main humaine. Mais si l'interprétation est incertaine (marque, format, quantité ambiguë), elle ne doit jamais se transformer silencieusement en vente. L'interface doit montrer ce qui a été reconnu, ce qui reste flou, et ce qui n'a pas été trouvé.
Une architecture locale, avec des dépendances à surveiller
Le code est structuré en modules distincts : caisse, inventaire, commandes, comptes clients, analytique, IA, son et persistance. Cette séparation a du bon sens : une amélioration de la recherche produit ne devrait pas obliger à réécrire tout le reste. Le projet utilise aussi des API natives du navigateur pour générer des sons, plutôt que de s'appuyer sur des fichiers audio externes.
Pour la persistance, la description parle d'un stockage local du navigateur et d'IndexedDB, sans backend cloud tiers obligatoire. L'intérêt est clair : continuer à travailler si la connexion est indisponible. Et comme les données restent sur l'appareil, le commerçant garde un peu plus la main.
Mais « local » ne veut pas dire « sauvegardé » ni « sécurisé par défaut ».
Un navigateur peut être réinitialisé, un appareil peut tomber en panne, et les données locales ne se synchronisent pas automatiquement entre deux caisses. Il faut donc prévoir des sauvegardes testées, une procédure de restauration, et, si plusieurs appareils sont utilisés, une stratégie de synchronisation capable de gérer les conflits. Sinon, l'indépendance du cloud peut finir en risque réel : perte de données, inventaire incohérent, ou factures à refaire.
La frontière du hors ligne mérite aussi d'être explicitée. La caisse et le catalogue peuvent fonctionner localement si l'application et les données sont déjà présentes. En revanche, l'appel à l'API Gemini dépend d'une connexion et envoie le texte de la liste à un service externe. Le QR UPI ne fait pas le paiement à lui seul. Et les éléments liés à la messagerie dépendent aussi des capacités du navigateur et des services concernés. Autrement dit : ce n'est pas parce qu'une partie de l'interface marche sans réseau que tout le système est « hors ligne ».
C'est aussi un enjeu de confidentialité. Les comptes clients peuvent contenir des noms, des numéros de téléphone et des soldes dus. Si le commerçant utilise l'IA ou des services de messagerie, il doit savoir quelles données quittent l'appareil, où elles sont traitées, et pendant combien de temps elles sont conservées. Dans un déploiement en Europe, il faudra aussi regarder les rôles des fournisseurs, les bases légales, les contrats et les transferts potentiels, au regard du RGPD.
Le dépôt GitHub de KiranaSetu et la documentation sont accessibles. Avant d'évaluer, mieux vaut vérifier l'état actuel du projet, les instructions d'installation, les dépendances, et les mécanismes de stockage tels qu'ils existent réellement - pas uniquement tels qu'ils sont décrits dans une démonstration.
Ce que le projet ne garantit pas encore
Le terme « zéro erreur » relève d'une intention de conception, pas d'une propriété qu'on peut garantir. Les calculs automatiques réduisent certaines erreurs, mais un prix mal saisi, une règle fiscale mal paramétrée ou un stock ajusté trop tard produit toujours un résultat faux - souvent plus vite et de manière plus systématique.
Le traitement fiscal présenté est spécifique à l'Inde. En France, une caisse destinée à un assujetti à la TVA doit respecter des exigences précises, et les règles dépendent de la situation du commerçant. Il ne suffit pas de remplacer la roupie par l'euro. Avant toute utilisation pro, il faudra valider la conformité réglementaire et comptable avec des sources adaptées.
La démonstration ne dit pas non plus si l'application résiste bien aux incidents. Pour en avoir le cœur net, il faudrait tester coupures réseau, redémarrages, erreurs de synchronisation, sauvegardes et restaurations. Il faut aussi vérifier les droits d'accès : un employé ne doit pas forcément pouvoir modifier les prix, consulter tous les comptes clients ou effacer des factures. Ces détails sont moins « visibles » que des fonctions d'IA, mais ce sont eux qui déterminent la durabilité.
Enfin, une application locale a des coûts opérationnels même sans abonnement cloud : installation, mises à jour, assistance, formation, sauvegardes et gestion des appareils. L'open source réduit le verrouillage fournisseur et permet d'inspecter le code, mais il ne garantit ni maintenance gratuite ni support immédiat. Pour un commerçant, l'équation à regarder, c'est le coût total et le temps réellement gagné, pas seulement le prix affiché.
Une évaluation sérieuse peut passer par quatre étapes :
- Choisir un flux à améliorer (par exemple le retrait de commandes ou le suivi des crédits), plutôt que de basculer tout le magasin d'un coup.
- Tester avec des données réalistes, y compris des produits vendus à l'unité, au poids, et sous plusieurs formats.
- Simuler les incidents : perte de réseau, appareil indisponible, restauration depuis sauvegarde.
- Mesurer les résultats : temps moyen de préparation, erreurs de facturation, écarts d'inventaire, avant d'élargir.
Cette approche évite de confondre une démo convaincante et un outil utilisable en conditions réelles. Et elle aide à savoir si la fonction répond au vrai problème du commerce.
Conclusion : partir du flux de travail, pas de l'IA
KiranaSetu m'intéresse surtout parce qu'il relie des tâches concrètes : vendre, vérifier le stock, préparer une commande, suivre un crédit et communiquer avec le client. Son approche modulaire et locale répond à des contraintes réelles, mais elle ne dispense pas de traiter les sauvegardes, la sécurité, la conformité et - crucial - la confirmation effective des paiements.
Pour un commerce de proximité, la bonne question n'est pas « faut-il adopter l'IA ? ». C'est plutôt : quelle tâche coûte aujourd'hui le plus de temps ou génère le plus d'erreurs, et comment la simplifier sans créer une nouvelle dépendance ? Commencez par un flux limité, mesurez ce que ça change, puis élargissez seulement si le système tient dans les conditions réelles.
Vous pouvez consulter le code source de KiranaSetu et examiner son fonctionnement avant d'envisager une adaptation. Un outil imparfait mais vérifiable, sauvegardé et utile au comptoir vaut mieux qu'une promesse ambitieuse dont les limites ne deviennent visibles qu'au moment d'une panne.