Faire tester son site par Claude dans Chrome : le guide

Peut-on faire tester son site par Claude dans le navigateur ?

Oui : l’extension officielle Claude in Chrome permet à Claude de lire ton site, cliquer, saisir du texte et remplir des formulaires dans un panneau latéral de Chrome, comme un visiteur. Elle exige un plan Claude payant, ne fonctionne que sur Chrome, et s’arrête avant les achats, créations de compte et CAPTCHA.

Ce tutoriel s’adresse aux dirigeants et responsables de site qui veulent un premier passage de contrôle avant une mise en ligne ou après une modification. Il ne remplace pas une recette complète, mais il attrape vite les erreurs visibles.

Prérequis

• Un abonnement payant à Claude : la fiche Chrome Web Store de l’extension le demande avant le démarrage.
• Google Chrome. Les autres navigateurs Chromium et les appareils mobiles ne sont pas supportés.
• Un profil Chrome dédié au test, sans session ouverte sur tes outils internes.
• Un compte de test créé à l’avance sur ton site, avec des données fictives.
• La liste des pages et des parcours à contrôler.

Étape 1 : installe l’extension et isole un profil

Installe l’extension depuis le Chrome Web Store, connecte-toi à ton compte Claude, puis ouvre le panneau latéral.

Crée d’abord un profil Chrome vide. La documentation Claude Code précise que Claude partage l’état de connexion du navigateur et peut donc accéder à tout site où tu es déjà connecté. Un profil propre limite ce risque à ton seul site de test.

Sur les offres Team et Enterprise, les administrateurs activent l’extension pour l’organisation et choisissent les sites autorisés.

Étape 2 : choisis le mode de permission

Il existe deux modes, décrits dans le guide des permissions Claude in Chrome :

Commence en mode manuel. L’injection de prompt est une attaque qui cache dans une page des instructions destinées à détourner l’IA de la tâche demandée. Anthropic mesurait 23,6 % de réussite pour ces attaques sans protection source : Anthropic, 2025. Ce taux est tombé à 11,2 % avec les mitigations du mode autonome source : The Register, 2025. Ces chiffres datent du pilote d’août 2025 et la documentation évolue vite, mais ils montrent pourquoi il vaut mieux valider soi-même le plan au début.

Étape 3 : prépare le compte de test et les données fictives

Claude ne crée pas de compte : l’action fait partie de celles que la documentation lui interdit, avec les achats et le contournement des CAPTCHA. Crée donc toi-même un compte de test.

Prépare aussi un jeu de données inventées :

• un nom et une adresse e-mail fictifs que tu peux relever dans ta boîte de test ;
• un téléphone et une adresse postale factices ;
• un message de contact court et reconnaissable, par exemple « TEST Peechy, ne pas traiter ».

N’utilise jamais ta vraie carte bancaire ni tes vrais identifiants dans la demande. Si ta boutique propose un mode test chez son prestataire de paiement, c’est ce mode qu’il faut employer pour le parcours de commande.

Étape 4 : écris un plan de test numéroté

Un plan de test précis donne de meilleurs résultats qu’une consigne vague comme « vérifie mon site ». Un retour d’expérience de développeur décrit cette méthode : prérequis, cas de test nommés, étapes numérotées. Prenons un exemple fictif, un site de cave en ligne :

Tu es testeur QA. Parcours https://exemple-cave.fr comme un visiteur.
Ne fais aucun achat et ne crée aucun compte.

Test 1 : formulaire de contact
1. Ouvre la page Contact.
2. Soumets le formulaire vide, note les messages d'erreur.
3. Soumets-le avec l'e-mail « test@exemple.fr » et le message « TEST, ne pas traiter ».
4. Indique si une confirmation s'affiche.

Test 2 : navigation
1. Clique chaque lien du menu principal et du pied de page.
2. Note toute page en erreur ou sans contenu.

Test 3 : parcours de commande
1. Ajoute un produit au panier.
2. Va jusqu'à la page de paiement, puis arrête-toi.
3. Note tout champ, bouton ou message incohérent.

Rends un compte rendu : OK / problème, URL, étape, description.

Pour un site en développement, la documentation officielle donne un exemple du même genre : ouvrir localhost:3000, soumettre le formulaire avec des données invalides et vérifier que les messages d’erreur s’affichent. Via Claude Code, Claude peut aussi lire les logs de la console et le DOM. Le DOM (Document Object Model) correspond à la représentation structurée de la page que le navigateur construit à partir du HTML. Pour le cas du développeur, voir notre tutoriel Claude Code jusqu’à Vercel.

Étape 5 : lis le compte rendu, puis vérifie toi-même

Traite le compte rendu comme une liste de pistes. Reproduis chaque problème signalé dans ton propre navigateur avant de demander une correction.

Deux limites à connaître. La documentation consultée ne décrit aucune simulation d’affichage mobile : l’extension tourne sur Chrome pour ordinateur, pas sur mobile. Contrôle donc l’affichage mobile toi-même, sur un vrai téléphone. Elle ne décrit pas non plus d’analyse systématique de tous les liens du site. Claude peut cliquer ceux que tu lui indiques, mais pour un inventaire exhaustif des liens morts, il faut un outil de vérification dédié.

Face à une page de connexion ou à un CAPTCHA, Claude se met en pause et te demande de t’en charger. Connecte-toi alors avec le compte de test seulement.

FAQ

Pièges courants

Un test par Claude attrape les erreurs visibles en quelques minutes, mais il ne remplace ni ton contrôle des parcours critiques ni une maintenance suivie. Si ton formulaire est signalé en panne, passe directement à la méthode de réparation.