Un assistant qui lit le prix et la disponibilité dans votre magasin au moment même où le client pose la question.
Nous relions l’assistant au catalogue de la boutique via sa porte publique, nous le plaçons sur les canaux où les clients écrivent déjà et nous lui donnons une règle qu’il ne peut pas enfreindre : ne pas annoncer un prix qui n’est pas publié dans la boutique. Lorsqu’il dépasse son rôle, il transmet la discussion à un humain, avec traçabilité.
Déjà construitSe poate verifica din exterior, fără să ne întrebi pe noi. Punctul nostru de catalog livrat unui distribuitor răspunde 200 și spune „154 rezultate”, iar interfața publică a magazinului lui, interogată direct, întoarce antetul `x-wp-total: 154` — aceeași cifră, două surse independente, 06.09.2026. A doua implementare e funcția de catalog din platforma de asistenți: `storeCatalog.service.js` plus trei unelte încorporate pe care agentul le poate chema în timpul conversației. Rezerva pe care o spunem înainte de contract: mesajele din șablon WhatsApp nu există în codul platformei, deci nu promitem niciun mesaj proactiv în afara ferestrei de 24 de ore; iar traseul de catalog stă pe o ramură de dezvoltare care nu e unificată în trunchi — e livrat pentru magazinele pe care le-am conectat, nu pornit implicit pentru toți.
Un assistant de boutique ne se casse pas parce qu’il ne comprend pas la question. Il se casse parce qu’il répond à partir d’une copie du catalogue. Quelqu’un a exporté les produits une fois, les a collés dans un fichier, et depuis lors l’assistant lit une vieille photographie de la boutique : le prix d’il y a trois semaines, le stock d’avant le week-end. Tout fonctionne parfaitement jusqu’au premier changement de prix et jusqu’au premier produit épuisé — et alors il se trompe avec assurance, ce qui est pire que de se taire. Dans le commerce, ce n’est pas une erreur de nuance : le client vient en magasin avec le prix que le bot lui a donné.
Notre choix est simple et a des conséquences : le catalogue n’est pas copié, il est lu. Pour les boutiques sous WooCommerce, l’interface Store API est publique — la connexion se fait donc avec l’adresse du site, sans clé consommateur ni secret. Quand le client demande un produit, l’agent appelle un outil, l’outil interroge la boutique, la boutique répond avec le prix et la disponibilité du moment. Ce qui apparaît dans la conversation est ce qui est dans la boutique, pas ce qui était au moment de l’intégration.
Le coût de ce choix est visible dans le code, pas caché : le catalogue se charge par pages, jusqu’à trente pages de cent produits chacune, il est conservé dans une mémoire temporaire de dix minutes par site et il est normalisé dans une seule forme, lue sans modification par tous les consommateurs — y compris le carrousel de produits de messagerie, qui a besoin d’un prix numérique, et le widget de page. Dix minutes est le compromis : un changement de prix effectué maintenant apparaît au plus tard dans dix minutes, pas instantanément. Nous donnons le chiffre, pour que vous puissiez le contester.
Le reste des limites ne vient pas de nous, mais des canaux, et il est plus honnête de les connaître avant : Meta refuse le texte libre en dehors de la fenêtre de 24 heures depuis le dernier message du client, Instagram n’a pas de carrousels de produits du tout, et une photo envoyée par le client est marquée dans la conversation, pas automatiquement attachée à une commande. Chacune de ces phrases est citée ci-dessous avec fichier et ligne.
Ce que cela comprend
Ce qui change concrètement dans le commerce en ligne
La question devient une recherche dans votre catalogue, pas une devinette
L’agent dispose de trois outils intégrés au-dessus d’un service de catalogue commun : `store_catalog_search` pour la recherche, `store_catalog_match` pour l’appariement d’une formulation client avec un produit précis, `store_catalog_product` pour la fiche complète. Ce ne sont pas des outils écrits séparément pour chaque boutique — ce sont des fonctions de la plateforme. La différence pratique : lorsque nous corrigeons quelque chose dans l’appariement, cela est corrigé pour toutes les boutiques connectées en même temps.
Le prix et le stock sont lus dans la boutique au moment de la question
Le résultat de l’outil vient de votre boutique, pas d’un fichier chez nous. La mémoire temporaire est de dix minutes par site, et le catalogue est parcouru par pages — jusqu’à 30 pages de 100 produits chacune. La conséquence que vous devez accepter : un changement de prix apparaît dans la conversation avec un retard de dix minutes au maximum. La conséquence que vous gagnez : il n’existe pas de scénario où l’agent répète pendant des mois un prix retiré de la boutique.
La réponse sort sur le canal qu’a utilisé le client
Six canaux ont leur propre code dans la plateforme : Messenger, Instagram Direct, Telegram, le widget de page, une plateforme locale d’annonces et WhatsApp via Cloud API sur Graph v22.0. Ce n’est pas un seul «chat» renommé six fois : chaque canal a ses propres règles de format et ses propres modes de panne, et nous vérifions aussi le mauvais cas — un token de page expiré arrête le canal en silence s’il n’est pas surveillé.
La connexion de la boutique sous WooCommerce se fait avec son adresse, sans clés
Store API est publique, donc nous ne vous demandons pas `consumer_key` ni `consumer_secret`. Ce n’est pas une commodité, c’est une décision de risque : les outils écrits à la main que ce trajet a remplacés gardaient, pour certains, des clés de boutique écrites en clair dans la base de données. Le nouveau trajet a remplacé 109 outils écrits manuellement, dont 28 étaient des scrapeurs sur HTML — c’est-à-dire des intégrations qui se cassaient au premier changement de thème de la boutique.
Le carrousel de produits a des conditions, et elles diffèrent d’un canal à l’autre
Sur Messenger, le carrousel ne s’affiche que lorsque trois conditions sont remplies simultanément ; si l’une manque, la réponse reste textuelle, elle ne se casse pas. Sur Instagram, il n’existe pas de carrousel de produits — Meta n’a pas de modèles génériques sur Instagram, donc personne ne peut livrer cela là-bas, quel que soit ce qui est écrit dans l’offre. C’est le genre de phrase que nous préférons que vous entendiez de notre part avant le contrat.
Fenêtre de 24 heures sur WhatsApp, dite avec le numéro de l’erreur
En dehors de la fenêtre de 24 heures depuis le dernier message du client, Meta rejette le texte libre avec l’erreur 131047, et le message reste marqué comme échoué dans la plateforme. Les messages de modèle — seul moyen légitime d’écrire en premier après la fenêtre — n’existent pas dans le code de la plateforme : une recherche par type `template` renvoie zéro résultat, seul le type `text` est envoyé. Donc : la récupération de panier abandonné sur WhatsApp à 48 heures, nous ne pouvons pas vous la promettre aujourd’hui.
Les rafales de messages et les messages en double sont traités, pas ignorés
Le webhook Meta renvoie bel et bien le même message : la déduplication se fait sur l’identifiant du message, avec 120 secondes de mémoire. Et le client qui écrit « bună », « aveți », « modelul negru » sur trois lignes reçoit une seule réponse à tout ce qu’il a écrit, pas trois réponses partielles — les messages s’agrègent dans un tampon de 15 secondes. En commerce, cela compte plus qu’il n’y paraît : trois réponses partielles à une seule intention ressemblent exactement à un robot.
Le transfert à un humain a un état, ce n’est pas une promesse
Le fil de discussion a un état explicite `bot` ou `human`. Le journal de prise en charge connaît trois actions : prise en charge par un humain, retour au bot, réactivation automatique. Séparément, le fil a un état de respect du temps de réponse — `ok`, `warning`, `breached` — donc on voit quelle conversation est restée sans réponse humaine, pas seulement combien il y en a eu.
Ce qu’un assistant de magasin ne résout pas
Il n’encaisse pas le paiement. Il ne crée pas la commande dans la boutique si la boutique n’a pas de voie d’écriture — la lecture est publique, l’écriture ne l’est pas. Il n’attache pas la photo envoyée par le client à une commande : la photo reçue est marquée dans la conversation, c’est tout, et la génération de PDF n’existe pas dans la plateforme. Et il ne répète pas la commande précédente d’un client sans accès autorisé à son historique. Chacun de ces éléments peut être construit, mais comme travail séparé, pas comme case à cocher dans l’offre.
Traseul
Comment une demande passe par le système.
01
Nous vérifions d’abord quelle gate publique possède votre boutique
La première vérification, pas la dernière : nous demandons le catalogue depuis l’extérieur et nous comptons ce qui revient. Si la boutique est sur WooCommerce avec Store API active, l’intégration n’a pas besoin de clés. Sinon, nous passons à l’authentification — et alors la clé devient un élément à administrer, avec tout ce que cela implique. Nous livrons le résultat de cette vérification par écrit, y compris quand la réponse est que ce n’est pas possible.
02
Nous connectons le catalogue et les canaux, avec le cas le plus désagréable testé
La connexion Meta se fait via Embedded Signup. Pour chaque canal, nous vérifions non seulement le premier message réussi, mais aussi ce qui se passe lorsque le token expire ou lorsque la boutique ne répond pas. Nous livrons les canaux connectés et la liste écrite du comportement pour chaque mode de défaillance.
03
Nous écrivons le rôle, les outils et la limite
Chaque outil a une description écrite pour le modèle, des paramètres typés et son propre délai d’exécution — par défaut 15 secondes. Le rôle de l’agent dit explicitement ce qu’il n’a pas le droit d’affirmer : prix non publié, délai de livraison, disponibilité qu’il n’a pas lue. Nous livrons la configuration de l’agent et la liste des outils qui lui sont attachés — pas tous les outils de la plateforme, seulement ceux dont il a besoin.
04
Nous démarrons avec la prise en charge humaine active et nous réglons les seuils
Nous démarrons avec le transfert à un humain configuré et avec le journal des requêtes activé, afin de voir quels fragments l’agent a utilisés et avec quels scores. À partir de là, le seuil de similitude et le nombre de fragments par question sont ajustés. Nous livrons un rapport de conversations avec les décisions de réglage, pas seulement un assistant démarré.
Traseul, în 5 pași
Les données
Ce que nous touchons, où elles sont et combien de temps elles restent
Les règles diffèrent d’une industrie à l’autre. Voici celles qui s’appliquent au commerce en ligne.
Le catalogue ne se copie pas chez nous
Les produits, les prix et le stock restent chez vous. Ce qui passe par la plateforme, c’est la réponse à une question, conservée en mémoire temporaire pendant dix minutes. Chez nous, il n’existe pas de base avec votre catalogue que quelqu’un puisse exporter, car il n’y a pas d’export à faire.
Où se trouvent les conversations
MySQL, sur le serveur propre dans Microsoft Azure. Le schéma comporte plus de 80 tables modélisées dans Prisma, avec des tables séparées pour les fils Meta, les fils Telegram, les fils de la plateforme d’annonces, les commentaires, les étiquettes, les notes internes et le journal d’audit. Le jeton du canal est conservé chiffré avec Fernet.
Les données de commande entrent dans un champ libre
Dans une conversation de magasin, arrivent le nom, le téléphone, l’adresse de livraison et, parfois, la taille ou le problème médical pour lequel le client achète le produit. On ne peut pas l’arrêter techniquement. On peut le traiter : on définit ce qui est conservé, combien de temps, qui y a accès et ce que l’équipe est formée à ne pas demander sur le canal. Le registre des traitements de l’implémentation se rédige lors de l’implémentation, pas après.
Le widget de la page et la liste des origines
Le widget a une liste d’origines autorisées par assistant, mais le comportement par défaut doit être connu : si la liste est vide, la vérification passe. C’est un choix de compatibilité avec les anciennes installations, écrit tel quel dans le code. En pratique, la restriction au domaine de votre magasin se configure explicitement à chaque implémentation — elle n’arrive pas déjà en place.
Le délai de conservation
Cela se définit par implémentation et se rédige dans la politique publiée par vous. La règle que nous appliquons chez nous et que nous demandons aussi dans les projets : si une modification de code change ce qui est collecté, à qui cela parvient ou combien de temps c’est conservé, la politique publiée est modifiée dans le même commit.
Un cas
Un catalogue de 154 produits, vérifié de deux côtés
La situation
Un distributeur de Chișinău vendait via une boutique WooCommerce et répondait à des questions sur les produits sur des canaux de messagerie. L’intégration évidente — un export de produits placé dans la base de connaissances de l’agent — aurait fonctionné jusqu’à la première campagne de réductions.
Ce que nous avons construit
Nous avons connecté le catalogue via l’interface publique de la boutique, qui ne demande pas de clés, et nous avons ajouté par-dessus trois outils que l’agent appelle dans la conversation : recherche, correspondance et fiche produit. Les résultats sont normalisés dans une forme unique, lue de la même manière par le carrousel de messagerie et par le widget de la page, afin qu’il n’existe pas deux vérités sur le même prix.
Ce qui en est sorti
La vérification peut être faite de l’extérieur, sans nous croire sur parole : notre point de catalogue répond 200 et rapporte 154 résultats, et l’interface publique de la boutique, interrogée directement, renvoie l’en-tête `x-wp-total: 154`. Le même chiffre, deux sources indépendantes, le même jour.
Ce que le cas ne dit pas
Le chiffre est celui de ce jour-là, le 06.09.2026, et il change lorsque le distributeur ajoute des produits — c’est l’idée. Ce n’est pas une mesure de performance et cela ne dit rien sur les ventes ; cela dit seulement que l’agent lit le catalogue réel.
Questions
Ce que quelqu’un demande dans le commerce en ligne
Comment savoir qu’il ne donne pas un ancien prix ?
Parce qu’il n’a pas d’où le prendre. Le prix vient de la réponse de votre boutique au moment de la question, conservé en mémoire temporaire pendant au maximum dix minutes. Chez nous, il n’existe pas de copie du catalogue à partir de laquelle il pourrait lire. Vous pouvez effectuer la vérification vous-même : vous demandez à l’agent un produit, vous changez le prix dans la boutique, vous attendez dix minutes et vous redemandez.
Que répond-il lorsque le produit est épuisé ?
Ce que dit la boutique. La disponibilité vient de la même réponse que le prix. Ce qu’il ne fait pas — et c’est une décision, pas un oubli —, c’est inventer une date de réapprovisionnement. Si vous voulez que l’agent propose des alternatives lorsqu’un produit manque, c’est une règle que nous écrivons explicitement dans son rôle et que nous testons, pas quelque chose qui se produit tout seul.
Peut-il finaliser la commande ?
Pas depuis la lecture du catalogue. L’API publique du store est une gate de lecture ; l’écriture d’une commande exige un chemin authentifié vers la boutique, donc un travail séparé, avec des clés à gérer. Ce qu’il fait aujourd’hui : il mène le client jusqu’au bon produit, au bon prix, et lui donne le lien ou transmet la discussion à un humain.
Peut-il écrire le premier à un client qui a abandonné son panier ?
Sur WhatsApp, non, en dehors de la fenêtre de 24 heures. Meta rejette le texte libre avec l’erreur 131047, et les messages de modèle n’existent pas dans le code de la plateforme. Sur Telegram et sur Messenger, dans les limites des règles de chaque canal, il existe des automatisations programmées qui relancent les conversations restées sans réponse, avec des compteurs visibles pour savoir combien sont parties et combien ont été sautées.
Ça fonctionne avec un carrousel de produits sur Instagram ?
Non. Meta n’a pas de modèles génériques sur Instagram, donc le carrousel n’existe pas là pour personne. Sur Messenger, il existe, mais il exige trois conditions simultanément ; quand l’une manque, la réponse reste du texte. Nous préférons vous le dire maintenant, pas à la troisième semaine d’implémentation.
Ma boutique n’est pas sur WooCommerce. Qu’est-ce qui change ?
La première étape change : au lieu de connecter l’adresse, nous vérifions quelle interface publique votre plateforme a et si elle répond assez vite pour une conversation. Si elle n’en a aucune, soit nous écrivons un connecteur authentifié — et alors nous discutons de qui administre la clé — soit nous disons qu’il n’est pas possible de faire honnêtement un catalogue vivant et nous restons sur une base de connaissances mise à jour périodiquement, marquée comme telle.
Le client envoie la photo du produit qu’il veut. Que se passe-t-il ?
La photo est marquée dans la conversation et y reste pour l’humain qui prend le relais. Elle n’est pas automatiquement jointe à une commande et aucun document n’est généré à partir d’elle — il n’existe pas de code pour cela. Un agent qui prétendrait avoir enregistré la commande à partir de la photo mentirait, et cela se découvre à la livraison.
Que se passe-t-il quand le client écrit quatre messages l’un après l’autre ?
Il reçoit une seule réponse, à tout ce qu’il a écrit. Les messages sont agrégés dans un tampon de 15 secondes avant d’être envoyés au modèle. À part cela, si la plateforme Meta renvoie le même message — et elle le fait — la déduplication sur l’identifiant du message, avec 120 secondes de mémoire, empêche une deuxième réponse.
Qui répond quand l’agent ne sait pas ?
Un humain de votre équipe, et la prise en charge se voit dans le système : le fil passe de l’état `bot` à `human`, le journal de prise en charge note qui et quand, et l’état de respect du temps de réponse montre si le fil est resté en suspens. Sans ce mécanisme, « confier à un opérateur » est une promesse que personne ne peut vérifier des mois plus tard.
Qu'est-ce que vous voudriez voir mieux fonctionner ?
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.