Bot de vente, tableau de bord d’administration et support IA

Contexte

Projet personnel mené de mai à août 2026 : une boutique de mes propres guides numériques, vendus par bot de messagerie et administrés depuis un back-office web. Dans la boutique, un guide est une famille de produits : il regroupe plusieurs pièces d’un même lot, que l’acheteur choisit parmi ses variantes. Trois services TypeScript partagent un seul fichier SQLite en mode WAL : le bot de vente, l’assistant de support et le dashboard Next.js. La boutique vend par un bot Telegram ; le code est né sur Discord, et la version Telegram tourne comme quatrième service depuis un dépôt frère, sur la même base et le même back-office. Seul sur le projet, j’ai vérifié chaque livraison par le typage et par 307 fichiers de tests. Le projet est terminé depuis fin août : je n’y apporte plus que des correctifs et des vérifications, sans nouvelle fonctionnalité majeure.

Le problème

Pour chaque vente, le bot réserve un lot de stock chiffré, attend un paiement venu de l’un des canaux, puis livre le guide par message privé. Un virement ne porte pas de référence de commande : deux commandes au même prix sont indiscernables. Une ligne de stock peut partir deux fois si la livraison relit le stock par acheteur et non par commande : c’est arrivé une fois. Côté support, une question mal formulée échappe à une recherche par termes exacts.

Architecture et décisions

Dans la base commune, le bot de vente et l’assistant ont des tables disjointes : commandes et stock pour le premier, guides, sessions et connaissance pour le second. Le stock est chiffré en AES-256-GCM, clé dérivée par scrypt, dans un format d’enveloppe commun au bot et au dashboard. Le dashboard lit sur une connexion WAL en lecture seule, sans jamais bloquer sur une écriture du bot.

Un dépôt séparé porte une autre version du même back-office. Une seule table de transitions y décrit les machines à états des commandes et des paiements ; celle des commandes est à sens unique. Les montants y sont des entiers de centimes. Les écritures monétaires y passent par des transactions BEGIN IMMEDIATE, verrouillées en écriture dès l’ouverture. Des triggers SQLite y rendent le journal d’audit immuable. L’anti-rejeu figure parmi les invariants de son schéma. À la différence de la version décrite plus haut, le bot et le dashboard n’y partagent ni format d’enveloppe ni dérivation de clé ; un test de contrat a été écrit pour déchiffrer côté bot ce que chiffre le dashboard.

Stock et paiements

La réservation est un seul UPDATE … RETURNING : il réserve les lignes disponibles du guide et de la variante demandés et renvoie exactement celles qu’il a prises. Une ligne ne peut être livrée qu’après avoir été réservée. Depuis l’incident, la livraison relit les lignes par référence de commande.

Les paiements entrent dans une boîte de réception en base, puis un worker les apparie aux commandes par un score : confirmation automatique à partir de 0,8, revue manuelle à partir de 0,6, refus au-delà de 2 % d’écart de montant. Pour les virements, un sel de −5 à +5 centimes rend chaque total unique parmi les commandes en attente de paiement. La confirmation d’un virement exige un montant exact, un nom d’expéditeur reconnu et un candidat unique. Un index unique sur méthode et référence de paiement interdit de rejouer un paiement sur deux commandes.

Assistant de support, indexation et diagnostic

Une session traverse des états : accueil, diagnostic, qualification, IA active, puis résolu ou escaladé. Le diagnostic est un arbre de questions par guide et par catégorie, à feuilles de réponse ou d’escalade. Sinon, l’IA répond à partir des guides découpés en fragments versionnés et hachés. La recherche est hybride : BM25 sur un index FTS5 pour les termes exacts, cosinus sur des embeddings pour le sens, fusionnés par Reciprocal Rank Fusion ; sans vecteurs, le lexical seul sert.

Chaque message garde ses jetons d’entrée et de sortie et sa latence ; la fiche de session en fait la somme.

Une résolution devient un candidat pour la base de connaissance, dédupliqué par hachage, qu’un humain approuve ou rejette. Un incident s’ouvre quand cinq utilisateurs distincts signalent la même catégorie en quinze minutes, seuils réglables par boutique.

Exploitation, rôles, audit et 2FA

Quatre rôles ordonnés : super-administrateur, administrateur, gestionnaire, lecteur. L’isolation par boutique se tranche côté serveur, dans une table d’attributions. Le cookie de boutique choisit la boutique courante parmi celles attribuées au compte ; un cookie modifié n’ouvre l’accès à aucune autre. La connexion combine mot de passe haché par bcrypt et TOTP ; cinq échecs verrouillent le compte quinze minutes, et un secret 2FA en attente d’activation expire en dix minutes. Les actions sensibles (révéler un lot, supprimer, exporter) exigent une ré-authentification : un jeton de cinq minutes dans un cookie httpOnly, lié à l’utilisateur et à son IP. Chacune écrit dans le journal d’audit l’utilisateur, l’action, la ressource, un détail plafonné à 8 Ko et l’IP.

Le monitoring alerte, sans doublon, sur un stock à cinq lots ou moins, une commande en attente depuis une heure ou un bot silencieux depuis cinq minutes.

Ce que j’ai appris, ce que je referais

La réservation du stock repose sur un UPDATE conditionnel et l’anti-rejeu des paiements sur un index unique : la base de données tient ces deux garanties. L’incident de double livraison venait d’une requête correcte mais mal bornée.

La liaison du jeton de ré-authentification à une action précise est codée mais optionnelle : un jeton vaut cinq minutes pour toutes les actions. L’isolation stricte reste derrière un drapeau, avec un repli « toutes les boutiques » pour un compte sans attribution. Je câblerais la liaison par action et j’activerais l’isolation stricte par défaut. Le module d’achat dépasse 8 000 lignes ; je le découperais avant toute nouvelle fonctionnalité.