IA locale pour les commerces : le carnet de crédit
Découvrez comment une IA locale aide les commerces à gérer crédits, stocks et paiements sans envoyer leurs données sur un serveur. Architecture et limites.
Un carnet de crédit, une IA locale : le commerce de proximité peut-il s'en passer ?
Dans beaucoup de commerces de quartier, le crédit client tient encore dans un carnet. Un nom, quelques achats, une somme à rembourser : c'est simple, mais ça colle aux habitudes du voisinage. Le hic arrive quand les commandes s'accumulent, que les paiements se font au rythme du quotidien et qu'il faut anticiper les stocks. Les applications censées aider finissent souvent par imposer une saisie au mauvais moment - au comptoir, pendant le service - et par déplacer des données sensibles vers un prestataire distant.
Le projet Udhaar part d'une question plus précise : est-ce qu'une IA peut aider sans exiger une connexion permanente et sans envoyer le registre des dettes dans le cloud ? Pensé autour d'une épicerie de quartier à Aurangabad, en Inde, il combine reconnaissance vocale, modèle de langage exécuté localement et outils de prévision. L'objectif n'est pas de remplacer le jugement du commerçant, mais de rendre ses informations plus faciles à saisir et à exploiter.
Voici comment le système fonctionne, ce que ses tests montrent vraiment, et ce qui reste fragile. Le point n'est pas seulement qu'il utilise plusieurs modèles : c'est la façon dont il évite les chiffres inventés, tout en gardant une réponse rapide au comptoir.
Le problème : un carnet simple, mais difficile à exploiter
Dans plusieurs régions du monde, les petits commerces accordent des achats à crédit à des clients connus. En Inde, ce crédit informel est souvent noté dans un khata ou udhaar. Au Mexique, aux Philippines et en Indonésie, on trouve d'autres termes pour des pratiques proches. Le principe reste le même : le commerçant note les achats, puis fait le point quand le client rembourse.
Ce registre a un avantage qu'on oublie vite : il est immédiatement disponible, ne dépend d'aucun abonnement ni d'aucune connexion, et s'insère dans un geste du quotidien. Le remplacer par une application n'a de sens que si le gain de temps dépasse la nouvelle friction.
La saisie est le premier obstacle
Au comptoir, le commerçant sert parfois plusieurs personnes à la fois, pèse des produits, répond aux questions. Lui demander de sortir un téléphone, chercher le bon client, sélectionner chaque article puis saisir un montant peut vite devenir une mauvaise ergonomie - même si l'application est « bien faite ». Une tâche qui prend quelques secondes finit par peser quand elle se répète des dizaines, voire des centaines de fois par jour.
Udhaar propose donc une saisie vocale ou écrite, dans plusieurs langues et mélanges. Une phrase du style « Patil Kaku, deux kilos de sucre et un litre d'huile, 210 à crédit » est convertie en entrée structurée : cliente, articles, quantités, montant et type de transaction. Le système s'appuie sur les tournures réellement utilisées au comptoir, pas sur un formulaire standard.
Le registre contient des données sensibles
Un carnet de crédit n'est pas qu'une liste de ventes. Il montre qui doit de l'argent, combien, et parfois comment les paiements se passent. Envoyer ces informations vers un serveur externe est difficile à justifier, surtout si le commerçant n'a pas une réponse claire sur le stockage, les accès et la durée de conservation.
Dans Udhaar, le registre reste dans un fichier SQLite sur l'ordinateur du magasin. La reconnaissance et l'analyse des phrases sont exécutées localement. Pour certaines prévisions, le projet utilise toutefois un service TabPFN hébergé : dans ce cas, il envoie des variables numériques anonymisées plutôt que les noms des clients ou les détails de leurs achats. Une option avec des poids ouverts exécutés localement est aussi évoquée pour les commerces qui veulent éviter tout recours à un service distant.
Cette nuance compte : « local » ne veut pas automatiquement dire « tout reste sur place ». Il faut vérifier, flux par flux, ce qui quitte réellement l'appareil - modèle par modèle - et documenter précisément ces points.
Une architecture locale, avec des limites explicites
Udhaar s'appuie sur des règles rapides, Gemma exécuté avec Ollama, faster-whisper pour la transcription, SQLite pour le registre et TabPFN pour certaines prédictions. Chaque composant a un rôle. Ce découpage compte autant que le fait d'utiliser un grand modèle de langage.
Saisir vite, corriger ensuite
Pour une nouvelle transaction, des règles déterministes créent d'abord une entrée en moins d'une milliseconde. Gemma relit ensuite la phrase en arrière-plan et peut proposer une correction. Comme ça, l'attente n'empile pas au moment où le comptoir est le plus chargé. Et si le modèle met du temps à charger ou rencontre un problème ponctuel, les règles peuvent continuer à fonctionner.
La sortie de Gemma est contrainte par un schéma JSON : le modèle ne renvoie pas un texte « libre » à interpréter une fois de plus, mais une structure attendue. Ce n'est pas une garantie que le contenu soit exact, mais ça limite les erreurs de format et rend la réponse plus facile à intégrer à l'application.
Le système fait aussi un contrôle de cohérence sur les montants. Si une entrée indique 920 roupies pour deux kilos de sucre alors que les transactions précédentes tournent plutôt autour de 92 roupies, l'application demande confirmation. Dans un registre de dettes, un zéro de trop n'est pas un détail : ça peut mener à réclamer une somme incorrecte. Le contrôle ne remplace pas la validation humaine, mais il force l'attention au bon moment.
Le modèle de langage ne décide pas du solde
Quand le système répond à une question, Gemma peut repérer l'intention - par exemple consulter le solde d'un client ou estimer une quantité de sucre - puis choisir les outils adaptés. Mais le chiffre affiché vient d'une requête SQL sur le registre ou d'une prédiction TabPFN. Le modèle ne « calcule » pas la dette en écrivant une réponse plausible.
C'est une séparation utile dès qu'on touche à des données financières : le modèle comprend la demande, une source vérifiable fournit le résultat. Une IA peut se tromper sur l'intention, mais elle ne devrait pas pouvoir inventer un montant. Chaque réponse vise aussi à conserver une trace : étapes, composants utilisés, temps d'exécution.
Pour un outil qui traite des dettes, une réponse explicable et vérifiable vaut mieux qu'une formulation convaincante dont personne ne peut contrôler l'origine.
Le système peut aussi générer un récapitulatif quotidien : comptes à relancer, produits à commander avant une période de forte demande, comparaison des ventes avec une journée « habituelle ». Les actions sont concrètes (préparer un message de rappel, dresser une liste pour le grossiste), et le commerçant garde la main avant l'envoi.
Les modèles testés : résultats et compromis
Le projet ne part pas du réflexe « plus gros = forcément meilleur ». Les essais comparent des règles seules, Gemma 3 en versions 1B et 4B, et des modèles de prévision. Les résultats aident à comprendre les compromis, mais ils ne sont pas une preuve en conditions réelles : les jeux de données décrits restent petits ou synthétiques.
Précision contre temps de réponse
Sur 18 phrases de comptoir construites pour le test, les règles seules donnent 12 entrées entièrement correctes, avec une latence inférieure à une milliseconde. Gemma 3 4B en produit 15, mais avec environ six secondes de latence sur l'ordinateur utilisé. Gemma 3 1B, autour de 3,5 secondes, n'en corrige que 9 entièrement.
Le modèle 4B demande environ 3,5 Go de mémoire vidéo. Sur une carte graphique limitée à 4 Go, une partie du calcul bascule sur le processeur. Le résultat est donc meilleur en précision sur ce petit test, mais la vitesse reste trop faible pour une vérification après chaque commande en heure de pointe. Le 1B tient mieux sur le matériel, sans dépasser les règles dans cette évaluation.
Le compromis retenu est pragmatique : les règles écrivent tout de suite, puis le 4B vérifie plus tard. Si la correction concerne un article, le commerçant peut la repérer d'un coup d'œil. Si l'erreur porte sur le montant, une validation explicite devient plus importante. Au final, la valeur dépendra de la capacité des utilisateurs à repérer et accepter les corrections - et ça, il faudra le mesurer sur un vrai comptoir.
Le multilinguisme met au jour les ambiguïtés
Une même suite de sons peut vouloir dire autre chose selon la langue. Dans l'exemple du projet, don correspond à « deux » en marathi, mais peut aussi être un titre dans un nom espagnol, du type « Don Pepe ». andi peut désigner des œufs en marathi et être un prénom en indonésien. Même les nombres changent : écriture et prononciation peuvent varier.
Les règles ont été ajustées avec des exemples de commerces mexicains, philippins et indonésiens, puis testées sur neuf phrases supplémentaires jamais vues pendant cet ajustement. Sur cet échantillon séparé, les règles reconnaissent entièrement 5 entrées et Gemma 3 4B en reconnaît 7. Ces chiffres ne permettent pas de conclure sur la robustesse globale du système dans ces langues : ils montrent surtout à quel point des règles calées sur un contexte peuvent casser dès que les formulations changent.
Prévoir les retards et la demande sans entraîner un grand modèle
TabPFN sert à estimer le risque qu'un compte soit payé en retard, tester l'effet d'un crédit supplémentaire et prévoir la demande selon le jour de la semaine, la période de paie et la proximité d'une fête. Pour la limite de crédit, le système examine plusieurs montants possibles et retient un seuil en tenant compte du risque estimé et du remboursement maximal observé sur une période.
Les prévisions sont comparées à une moyenne simple des quatre semaines précédentes. Dans les périodes ordinaires, les erreurs restent proches. À l'approche de fêtes, TabPFN fait mieux que cette moyenne sur les données du test. Pour les retards, TabPFN dépasse aussi la règle « s'inquiéter après un mois sans paiement ».
Attention toutefois : ces résultats reposent sur treize mois d'historique synthétique, construit pour reproduire des effets (week-ends, paies, périodes de fête). On n'est donc pas sur des mesures prises dans des carnets réels. Le gain annoncé pour TabPFN reste une piste à vérifier sur le terrain.
| Test présenté | Méthode de référence | Résultat TabPFN |
|---|---|---|
| Prévision des stocks, période ordinaire | Erreur de 26 % | 24 % |
| Prévision, montée vers Ganesh Chaturthi | Erreur de 27 % | 20 % |
| Risque de retard de paiement | AUC de 0,67 pour la règle simple | AUC de 0,82 |
Le projet indique aussi un taux de détection de 60 % pour TabPFN, contre 40 % pour la règle simple. Là encore, ce n'est pas directement transposable à un commerce français : ça dépend des données, de la définition d'un retard et du niveau de risque acceptable.
Ce que le projet change - et ce qu'il reste à vérifier
Udhaar est intéressant moins comme « preuve qu'une IA omnisciente est possible » que comme étude sur la conception d'un outil contraint. Le modèle de langage n'a pas besoin de connaître tout le commerce. Les données transactionnelles restent locales ; les variables pour les prédictions restent limitées ; les actions sensibles sont contrôlées par le commerçant. En bref : une architecture plus sobre qu'un assistant à qui on demanderait de décider tout seul.
Pour le marché indien, le modèle économique annoncé est de 149 roupies par mois, soit moins qu'un achat mensuel de sucre pour l'épicerie citée. L'idée est simple : quelques relances plus rapides ou la correction d'erreurs de saisie pourraient compenser l'abonnement. Mais c'est encore un calcul à tester, car il faudra mesurer le vrai temps gagné, la fréquence des erreurs évitées et la volonté des commerçants de payer.
Ce qu'un déploiement en France devrait adapter
Un outil conçu pour une épicerie à Aurangabad ne se transpose pas « au même niveau » vers une boulangerie, une épicerie ou un autre commerce de proximité en France. Les langues, les unités de vente, les pratiques de crédit et les logiciels utilisés ne sont pas les mêmes. Il faudra aussi penser l'intégration avec la caisse et les outils comptables existants, au lieu d'ajouter une double saisie.
La protection des données doit être évaluée avant tout pilote. Les dettes et les habitudes d'achat renvoient à des personnes identifiables : l'entreprise qui déploie le service doit fixer les finalités, les durées de conservation, les accès et les mesures de sécurité, conformément au RGPD. Le « local » réduit certains transferts, mais ne suffit pas à garantir la conformité. Sauvegardes, mises à jour, journaux, et d'éventuelles requêtes vers un service distant comptent aussi.
Enfin, une prédiction de risque ne doit pas devenir une décision automatique de refus de crédit. Le commerçant doit comprendre le signal, pouvoir contester une donnée erronée et intégrer le contexte humain. Une estimation statistique n'est pas une certitude sur le comportement futur d'une personne.
Le principal test n'a pas encore eu lieu
La créatrice du projet explique avoir observé les commandes consignées dans un commerce d'Aurangabad et avoir construit Udhaar pour ce contexte. Au moment de la publication initiale, l'application n'avait pas encore été utilisée par un commerçant dans un test réel : un essai au comptoir était seulement annoncé. Cette précision change la lecture du projet. Les performances du prototype et les résultats sur données synthétiques ne prouvent pas encore qu'il tiendra face au bruit du quotidien, aux accents, aux commandes interrompues et aux corrections faites pendant le service.
Le code, sous licence MIT, et une démonstration sont disponibles en ligne : dépôt Udhaar sur GitHub et démonstration du projet. L'installation s'appuie notamment sur Ollama, Gemma, FastAPI et SQLite. Pour un déploiement réel, il faudrait aussi prévoir les sauvegardes hors ligne, la récupération après panne et une procédure simple de correction des données.
Conclusion : commencer par le flux de travail
Udhaar défend une idée assez simple : une IA devient vraiment utile quand elle s'insère dans le travail existant plutôt que quand elle ajoute un outil de plus à faire tourner. Ici, les règles prennent en charge la saisie immédiate, Gemma fait une seconde lecture et le registre reste la source des soldes. TabPFN explore des prévisions que le carnet seul ne peut pas produire.
Mais pour l'instant, on parle d'un prototype à valider. Les chiffres viennent de tests limités et de données synthétiques ; l'essai au comptoir devra montrer si la latence, la reconnaissance vocale et les recommandations tiennent pendant le service. Et, pour les projets d'IA métier, la leçon paraît claire : commencez par le geste qui fait perdre du temps, définissez quelles données peuvent quitter l'appareil, puis mesurez les erreurs sur le terrain.
Pour examiner l'implémentation et les résultats, regardez le code d'Udhaar. Si vous concevez un outil du même type, testez d'abord le flux de saisie avec les personnes qui l'utiliseront chaque jour, avant d'empiler davantage de modèles.