Quand nous avons connecté Provedly aux assistants IA, une question de conception comptait plus que toutes les autres. Un assistant doté d'une clé d'écriture peut mettre des widgets en pause, créer et modifier des barres et ajouter des enregistrements. Devait-il aussi pouvoir marquer un enregistrement comme vérifié ?
La réponse est non, pour toute clé, via tout outil, sur tout plan. Cet article explique où passe cette limite et pourquoi nous l'avons placée là.
Ce que « vérifié » veut dire dans Provedly
Un enregistrement porte la marque Vérifié quand il arrive chez Provedly par un webhook signé de Stripe, Shopify ou WooCommerce, et que la signature correspond au secret configuré pour cette connexion. La plateforme de la boutique signe le contenu ; Provedly vérifie la signature à l'arrivée. Si elle correspond, l'enregistrement ne peut provenir que de cette plateforme, et décrit une commande qu'elle a traitée.
C'est toute la définition. Elle est volontairement étroite. La marque Vérifié fait une affirmation précise, à savoir qu'un système de paiement a signalé cet achat, et c'est la seule affirmation du widget qu'un visiteur n'a pas à croire sur parole. La page de vérification publique liste les sources et les totaux de chaque widget pour qu'il puisse vérifier.
Le mécanisme est détaillé dans comment fonctionnent les notifications d'achats vérifiés et les secrets de signature des webhooks expliqués.
Ce qu'un assistant peut faire avec les enregistrements
Avec une clé en lecture et écriture, un assistant peut appeler add_record, et un backend peut appeler POST /widgets/{token}/records. Les deux sont utiles. Beaucoup d'achats réels ne passent pas par une boutique connectée : une facture payée par virement, une commande prise par téléphone, une vente sur une plateforme sans webhook signé.
Les enregistrements ajoutés de cette façon conservent la source API et portent une étiquette visible « Imported ». Ils s'affichent dans le widget, ils apparaissent dans les totaux de la page de vérification sous leur propre source, « Site owner's backend (API) », et ils ne portent jamais la marque Vérifié. Aucun champ de l'API ne permet de la définir et aucun outil ne la modifie ensuite, quelle que soit la clé.
Pourquoi cette limite existe
Réfléchissez à ce que prouve une clé. Une requête avec une clé Provedly valide prouve que l'appelant détient la clé. Elle ne dit rien sur le fait que de l'argent ait changé de mains. Un webhook signé, c'est différent : la signature est produite par la plateforme de paiement, avec un secret que cette plateforme ne partage qu'avec vous et Provedly.
Si un appel d'API pouvait marquer un enregistrement comme vérifié, la marque Vérifié signifierait « quelqu'un qui a la clé l'a dit ». C'est ce que proposent déjà la plupart des outils de notification : un formulaire où vous tapez un nom, une ville et un produit, et une notification identique à une vraie. Les visiteurs ont appris à ne pas s'y fier, et la règle de la FTC sur les faux avis a fait de la preuve sociale inventée une question juridique autant qu'une question de confiance.
Un assistant IA rend le problème plus aigu, pas différent. Il est très doué pour produire en quantité des noms, des villes et des produits plausibles. Placez cela à côté d'un bouton de vérification et vous obtenez un générateur de fausses notifications qui fonctionne en une phrase. Nous préférons que l'assistant soit incapable de le faire plutôt que de compter sur son refus.
Les prompts qui se heurtent à la limite
Certains essaieront. Voici ce qui se passe :
| Demande | Résultat |
|---|---|
| « Marque les cinq derniers enregistrements comme vérifiés » | Aucun outil ne le permet ; l'assistant le dit |
| « Ajoute 20 achats depuis différentes villes » | Ajoutés, étiquetés Imported, si la clé peut écrire |
| « Fais afficher 30 personnes au compteur de visiteurs » | Impossible ; le décompte reflète une présence réelle |
| « Importe mes commandes Stripe comme vérifiées » | Connectez le webhook Stripe ; lui seul vérifie |
La deuxième ligne mérite qu'on s'y arrête. Une clé d'écriture peut ajouter des enregistrements, et Provedly ne peut pas savoir si un nom que vous dictez appartient à un vrai acheteur. C'est précisément pourquoi ces enregistrements portent une étiquette plutôt qu'un badge. Si vous utilisez add_record pour autre chose que de vrais achats, l'étiquette et la page de vérification diront ce qu'ils sont, à quiconque regarde.
Ce que cela vous apporte
La limite est une contrainte, et c'est aussi ce qui donne sa valeur au produit. Comme la marque Vérifié ne peut pas être produite depuis une fenêtre de chat, elle a encore un sens quand un visiteur la voit, et le lien vers la page de vérification présent sur chaque badge lui permet de le confirmer. Un concurrent qui affiche « vérifié » à ses visiteurs à l'aide d'un simple interrupteur ne peut pas offrir la même chose.
Elle vous protège aussi de vos propres outils. Une clé divulguée, un script bogué ou un assistant qui a mal compris un prompt peuvent ajouter des enregistrements étiquetés que vous supprimerez ensuite. Aucun d'eux ne peut placer un faux Achat vérifié sur votre page publique.
Questions fréquentes
Puis-je vérifier des enregistrements provenant d'une plateforme que Provedly ne connecte pas ?
Pas en tant que Vérifié. Envoyez-les via l'API Records, où ils apparaissent avec l'étiquette Imported. Si la plateforme propose des webhooks signés, c'est la voie vers une future connexion.
Les enregistrements API nuisent-ils à mon widget ?
Ils s'affichent avec l'étiquette Imported, sans la marque Vérifié, et sont comptés sous leur propre source. Pour de vrais achats issus d'autres canaux, c'est exact et les visiteurs peuvent voir pourquoi.
Un futur plan ou réglage pourrait-il autoriser la vérification par IA ?
Non. La vérification repose sur une signature de la plateforme de paiement, et aucun plan ni réglage ne la remplace.
Créez un compte gratuit et connectez Stripe, Shopify ou WooCommerce pour voir arriver des enregistrements vérifiés.