Kolloh Store : une plateforme de commerce pilotée depuis une conversation

Le problème

Un petit commerçant gère son activité à travers cinq applications. Les commandes arrivent dans une conversation, le stock est dans sa tête, les promotions se décident à l’instinct, et le temps qu’il remarque qu’un habitué a cessé de commander, ce client achète ailleurs.

Les créateurs de boutiques répondent à cela par un tableau de bord. Mais un tableau de bord est un endroit où il faut penser à se rendre, et un commerçant qui sert des clients toute la journée ne s’y rend pas. L’intuition derrière Kolloh est que la couche opérationnelle doit venir au commerçant, dans l’application déjà ouverte sur son téléphone, plutôt que de l’attendre dans un onglet.

L’agent, pas le tableau de bord

Un agent propulsé par Claude fonctionne dans Telegram. Les nouvelles commandes arrivent dans la conversation avec des boutons pour confirmer, préparer ou marquer comme prête, de sorte qu’une commande passe de reçue à livrée sans ouvrir de tableau de bord. Il rédige un résumé des ventes au lever du jour, puis un second en fin de journée.

Il surveille aussi ce qu’un commerçant occupé ne verra pas : un habitué devenu silencieux est signalé avec une offre déjà rédigée, un nouvel avis arrive accompagné d’une réponse à valider ou modifier, et un stock faible déclenche une alerte avant la rupture plutôt qu’une excuse après.

Le tableau de bord existe toujours pour ce qui nécessite réellement un grand écran. Il a simplement cessé d’être la seule porte d’entrée.

La couche de machine learning

Un service Python distinct, bâti sur FastAPI, prend en charge ce pour quoi les modèles de langage ne sont pas l’outil adapté. Prophet produit une prévision de demande à quatorze jours avec un intervalle de confiance plutôt qu’une estimation unique. La détection d’anomalies signale les journées de vente qui ne collent pas, calibrée sur les week-ends et jours fériés locaux plutôt que sur un calendrier occidental. La valeur vie client est estimée avec scikit-learn, segmentant les acheteurs en champions, réguliers et à risque.

Il fonctionne comme un service authentifié à part plutôt qu’à l’intérieur de l’API principale, afin qu’un calcul lent ne bloque pas le passage en caisse d’un client et que la partie data science puisse évoluer sans redéployer la boutique.

Une génération de contenu adaptée au marché

Les commerçants vendent sur les réseaux sociaux, l’agent produit donc les visuels correspondants. Une photo de produit devient une bannière à leur image, au format exact d’Instagram carré ou story, de Facebook ou de TikTok, accompagnée d’une légende avec accroche, prix et hashtags. Une promotion reprend automatiquement le badge de remise, l’ancien prix barré et le code promo.

Les légendes se génèrent en arabe, en français ou en anglais avec un traitement correct du sens droite-à-gauche — pas une traduction ajoutée après coup. Une photo prise dans la boutique revient avec l’arrière-plan remplacé par un fond neutre et propre.

Multi-pays dès le premier jour

Le pays est la frontière de tenant. Devise, règles fiscales, catégories, pièces justificatives et prestataires de paiement, livraison et SMS disponibles sont tous configurés par marché, de sorte qu’un lancement dans un second pays relève de l’administration et non d’une duplication.

En dessous se trouvent neuf applications : une API NestJS sur Fastify, quatre interfaces Next.js, des workers, l’agent Telegram et le service ML. La gouvernance repose sur un modèle de permissions à six rôles, où l’autorité d’un administrateur pays s’arrête à son propre marché. La recherche utilise Meilisearch auto-hébergé, retenu après avoir chiffré les alternatives facturées à l’usage aux volumes attendus.