Corthex · WooCommerce / Identité du client
Quelle commande le chatbot a-t-il le droit de voir ?
Une réponse sur le suivi de commande commence par l’identité du client, puis la connexion à la boutique. Connaître un numéro de commande ne signifie pas avoir le droit de la consulter.
Schéma des autorisations · Exemple fictif
Avec connecteur et outils activés, utilisez le contexte client vérifié pour demander sa commande. La réponse réelle de la boutique détermine ce qui peut être répondu.
Un compte client définit un périmètre d’accès, pas seulement un accueil.
Lorsqu’un acheteur demande où en est sa commande, deux tâches distinctes s’imposent. Déterminez d’abord quel client la boutique a réellement authentifié. Demandez ensuite les informations qui appartiennent à ce client. Le message de chat ne prouve pas la propriété : quelqu’un peut saisir une adresse e-mail connue ou copier un numéro sur un reçu. Ces informations ne servent de contexte de recherche qu’après réception de l’identité vérifiée requise par la boutique.
Les outils natifs WooCommerce de Corthex pour ses propres commandes utilisent le client de boutique connecté et vérifié. Cette identité est distincte d’un compte administrateur Corthex, d’un formulaire de contact facultatif ou de l’historique du visiteur. Installer le widget sur une page ne transforme aucun de ces éléments en session client. Testez le compte client sur la boutique où fonctionne le widget, sans vous fier à l’aperçu du tableau de bord administrateur.
Quatre conditions réunies dans la même boutique.
Installez et activez l’extension Corthex AI avec WooCommerce actif. Utilisez Connect to Corthex dans WordPress, choisissez l’assistant prévu et confirmez l’association. Activez les outils e-commerce concernés pour cet assistant. Ouvrez enfin la boutique avec un compte client connecté auquel appartient la commande de test. Une réponse de chat générique prouve que l’assistant répond, sans rien prouver à elle seule sur cette chaîne de quatre éléments.
L’extension s’associe avec un jeton de connecteur limité ; aucune clé API REST WooCommerce manuelle n’est nécessaire. Le partage complet du profil des clients connectés est activé sur les nouvelles installations WordPress et peut être désactivé ; les réglages existants sont conservés. Ce réglage n’ouvre pas les commandes aux invités et ne remplace pas l’identité client vérifiée. Avec la seule intégration JavaScript générique, évaluez d’abord le besoin d’un connecteur natif ou d’une intégration sur mesure conçue délibérément.
Gardez explicite l’association entre assistant et boutique lorsque vous testez plusieurs boutiques ou environnements. Une préproduction liée à un assistant et une conversation de production ouverte sous un autre ne constituent pas un test d’accès utile. Notez environnement, nom d’assistant, version de l’extension et rôle client. Utilisez des commandes fictives et vos comptes de test ; ni transcriptions clients ni vraies adresses de livraison ne sont nécessaires comme preuves.
Un statut de commande n’est pas une promesse du transporteur.
Séparez trois questions : la boutique a-t-elle accepté la commande, quel est son statut actuel et quand le colis arrivera-t-il ? Les statuts WooCommerce décrivent son traitement. « En cours » et « Terminée » y ont un sens précis, sans fournir à eux seuls un scan du transporteur ou un rendez-vous de livraison. Des extensions d’expédition peuvent ajouter des données, mais leur disponibilité doit être vérifiée dans votre configuration connectée.
Une réponse utile indique ce que la boutique a réellement renvoyé et explique ce qui reste inconnu. Par exemple : la commande fictive de test est en cours de traitement ; le résultat disponible ne contient aucune date de livraison, donc l’assistant ne peut pas confirmer une arrivée demain. Une politique de livraison peut expliquer les délais habituels, mais ne doit pas être présentée comme l’état d’expédition réel de cette commande privée. Si l’information demandée manque, proposez l’assistance de la boutique sans prétendre que la recherche a abouti.
Vérifications reproductibles des autorisations
Testez le refus aussi soigneusement que la réponse.
Son propre compte, sa propre commande
Connectez le client de test A. Demandez le statut actuel de sa commande. Comparez la réponse aux données de la boutique et au résultat de l’outil, pas à une date de livraison supposée.
Réussite : seul le contexte de commande du client autorisé est utilisé. Les champs manquants sont reconnus. Conservez une capture expurgée et l’état attendu.
Invité connaissant le numéro
Déconnectez-vous ou utilisez une fenêtre privée. Donnez le même e-mail et numéro de commande dans le chat. Ils ne doivent pas remplacer la connexion requise.
Réussite : aucun détail privé de commande n’est révélé. Le visiteur reçoit un parcours utile de connexion ou d’assistance, sans confirmation de l’existence de la commande d’autrui.
Un autre client connecté
Connectez le client de test B et demandez la commande de A. Vous distinguez ainsi la propriété de la condition bien plus faible d’une simple connexion.
Réussite : la recherche ne franchit pas le périmètre du client. Rejouez après déconnexion, changement de compte ou modification de connexion ou de gestion des sessions.
Définissez la suite lorsque l’accès est indisponible.
Un refus sûr doit aider le client à poursuivre. Indiquez quel compte boutique utiliser, renvoyez vers l’espace client habituel si nécessaire ou expliquez comment l’assistance peut vérifier la demande selon sa procédure. Ne demandez jamais de mot de passe et ne copiez pas d’identifiant API privé dans le chat. En expliquant la limite, évitez de révéler si une commande sans lien avec le client existe.
Si le transfert est configuré sur Pro ou une formule supérieure, testez-le séparément avec l’équipe en ligne et hors ligne. Une demande en attente diffère d’une réponse immédiate. Notez la suite promise et vérifiez que l’équipe peut réellement l’assurer. En cas d’échec plus tôt dans la chaîne, utilisez le guide de diagnostic plutôt que d’élargir l’accès aux données clients.