Provedly s'installe avec une seule balise script, environ 6 Ko compressés en gzip, rendue dans un Shadow DOM pour ne pas entrer en conflit avec vos styles. C'est donc une tâche idéale pour un agent IA de code : donnez-lui le snippet, indiquez-lui où se trouve votre layout et demandez-lui de vérifier. Cet article vous propose un prompt à coller tel quel et une liste de points à contrôler ensuite.
Ce dont l'agent a besoin de votre part
Les agents s'en sortent bien avec des informations concrètes et mal avec des suppositions. Avant de commencer, rassemblez :
- Le snippet de script de votre site, depuis le dashboard Provedly. Il contient l'identifiant de votre site ; ne laissez pas l'agent en inventer un.
- L'emplacement de votre layout commun. Le fichier qui enveloppe toutes les pages : le root layout dans Next.js, un layout Blade dans Laravel, un template de base dans Django,
header.phpdans un thème WordPress. - Les pages qui doivent afficher la preuve. Le ciblage se configure dans Provedly, pas dans le code, mais l'agent doit savoir qu'il ne faut pas ajouter de logique conditionnelle de son cru.
- Si vous utilisez Stripe. Dans ce cas, vous voudrez aussi configurer l'endpoint de webhook pour que les achats arrivent vérifiés.
Les boutiques Shopify n'ont besoin de rien de tout cela. L'app Shopify de Provedly utilise une extension d'app de thème que vous activez dans l'éditeur de thème, sans toucher au code.
Un prompt à coller
Adaptez les parties entre crochets et donnez-le à votre agent.
Add the Provedly social proof script to this project.
Snippet (use exactly as given, do not modify the site id):
[paste the script tag from the Provedly dashboard]
Requirements:
- Add it once, in the shared layout so it loads on every page:
[path to your layout file]
- Place it before the closing </body> tag, or use the framework's
standard mechanism for third-party scripts (for example next/script
with a non-blocking strategy).
- Do not add page-level conditions; targeting is configured in Provedly.
- Do not add any other analytics or tracking.
- Do not create sample data or placeholder records anywhere.
Then verify:
- Start the dev server and confirm the script tag is present in the
rendered HTML of two different pages.
- Confirm there are no console errors from the script.
- Confirm the script does not block rendering.
Report what you changed and the result of each check.
Le dernier bloc compte. Demander à l'agent de vérifier et de rendre compte l'empêche de crier victoire après une seule modification.
Notes par framework
Next.js (App Router). L'agent doit placer la balise dans le root layout, en général avec next/script et une stratégie lazy ou after-interactive pour qu'elle ne bloque jamais l'hydratation. Un seul emplacement couvre toutes les routes.
Laravel avec Blade ou Inertia. Le layout Blade racine qui enveloppe l'application est le bon endroit, juste avant </body>. Une app Inertia a toujours une seule vue racine, donc une seule modification suffit.
WordPress. Le template de pied de page du thème, ou une petite extension qui charge le script dans le footer. Évitez de le coller dans des templates de page individuels.
Sites statiques et HTML simple. L'include de pied de page commun. Si les pages ne partagent pas d'include, l'agent doit l'ajouter à chaque page, mais c'est le signe qu'il faudrait d'abord créer un include commun.
Shopify. Ne touchez pas au code du thème. Installez l'app, approuvez la facturation Shopify et activez l'embed Provedly dans le panneau des app embeds de l'éditeur de thème. L'app enregistre les webhooks de commande pour vous.
Les détails d'installation pour chaque cas sont tenus à jour dans /docs.
Ce qu'il faut vérifier une fois l'agent terminé
Les agents rendent des rapports très sûrs d'eux, alors vérifiez vous-même quelques points.
| Vérification | Comment |
|---|---|
| La balise est dans le layout commun, une fois | Cherchez le snippet dans le code ; une seule occurrence |
| Elle s'affiche sur de vraies pages | Affichez la source de deux pages, dont une page profonde |
| Elle n'est pas bloquante | Chargée après le contenu principal ; aucun décalage de mise en page |
| Le Shadow DOM est en place | Inspectez la notification ; elle vit dans un shadow root |
| Le ciblage fonctionne | Ouvrez une page exclue et constatez que rien ne s'affiche |
| La taille est celle attendue | Le panneau Réseau montre un petit script compressé en gzip |
Si l'agent a ajouté un rendu conditionnel, des vérifications d'environnement ou des wrappers que vous n'avez pas demandés, supprimez-les. Le script est conçu pour être intégré tel quel, et le ciblage par URL et par appareil de Provedly décide quelles pages affichent quoi. Les règles de ciblage elles-mêmes sont expliquées dans /blog/where-to-show-social-proof-page-targeting.
Faire arriver les achats vérifiés
Le script affiche la preuve ; il ne la crée pas. Pour que les notifications portent la mention Achat vérifié, les achats doivent arriver par un webhook signé.
Pour Stripe, cela signifie ajouter un endpoint de webhook dans votre dashboard Stripe pointant vers l'adresse fournie par Provedly, puis coller le secret de signature dans Provedly. Un agent peut aussi vous aider ici, mais faites attention à ce que vous lui confiez : le secret de signature est sensible, et sa place est dans les réglages de Provedly, pas dans votre dépôt. Les événements exacts auxquels s'abonner sont listés dans /docs, et le parcours complet du checkout à la notification est décrit dans /blog/how-verified-purchase-notifications-work.
Tant que le premier webhook n'est pas arrivé, le widget n'a rien de vérifié à afficher. Résistez à la tentation de demander à l'agent de créer des enregistrements. Tout ce qui est ajouté à la main est étiqueté Sample, et tout ce qui vient d'un CSV est étiqueté Imported. Les exemples sur un site en ligne servent aux aperçus, et les imports servent aux vraies commandes passées, pas à combler un silence. Voir /blog/sample-records-labelled-honestly.
Les erreurs des agents sur cette tâche
Quelques comportements à surveiller, d'après la manière dont les agents de code ont tendance à agir :
- Inventer un identifiant de site quand le snippet n'a pas été fourni. Collez toujours le vrai snippet.
- Ajouter la balise dans plusieurs templates au lieu du template commun, ce qui provoque des chargements en double.
- Envelopper le script dans des vérifications d'environnement pour qu'il ne s'exécute qu'en production, ce qui rend toute vérification locale impossible. Le plan gratuit et le ciblage de Provedly permettent de l'exécuter en local sans risque.
- Écrire un faux composant de notification au lieu d'installer le script, parce que l'agent a compris la tâche comme « construire une notification ». Le prompt ci-dessus évite cela en demandant d'utiliser le snippet tel quel.
- Annoncer un succès sans avoir affiché une seule page. Demandez des preuves.
Aucun de ces pièges n'est difficile à repérer si vous regardez. L'installation elle-même tient en une ligne ; le soin se met dans la vérification.
Questions fréquentes
Le widget a-t-il besoin d'une configuration dans le code ?
Non. Tous les réglages de ciblage, de timing et d'apparence se trouvent dans le dashboard Provedly. La modification du code se limite à la balise script.
L'agent peut-il configurer le webhook Stripe à ma place ?
Il peut vous guider dans les étapes du dashboard Stripe, mais c'est à vous de saisir le secret de signature dans Provedly, en le gardant hors du dépôt et, autant que possible, hors du contexte de l'agent.
Le script va-t-il affecter les performances de la page ?
Il pèse environ 6 Ko compressés en gzip et se charge sans bloquer le rendu s'il est placé comme décrit. Le Shadow DOM isole ses styles des vôtres.
Récupérez votre snippet dans le dashboard après votre inscription sur /register, et gardez /docs ouvert pour les détails propres à votre framework.