Pourquoi une connexion MCP de test d'applications web vaut mieux que la lecture du code
Une lecture statique d'une application web vous dit ce que le code a l'intention de faire. Elle ne vous dit pas ce que le navigateur en fait. C'est dans l'écart entre les deux que vivent la plupart des défauts visibles par l'utilisateur, et cet écart se creuse à mesure qu'une part croissante du code provient d'un agent qui n'a jamais vu l'application s'afficher.
Ce qui est détecté et qui échappe à la relecture
L'état qui survit
Une fenêtre modale laisse le défilement bloqué, un filtre persiste dans un contexte où il n'a aucun sens.
Visible seulement à la deuxième interaction, jamais dans un diff.
Le rendu avant les données
La page s'affiche, la requête aboutit, et rien ne se réaffiche.
Reproductible de manière fiable en utilisant l'application, pratiquement invisible autrement.
Le deuxième compte
Des hypothèses de propriété et de visibilité qui tiennent pour la session du développeur et pour personne d'autre.
Le développement local
Le travail sur une application web se fait sur localhost bien avant tout déploiement, et une vérification qui n'atteint qu'une URL publique arrive trop tard pour influencer ce que vous construisez. Les cibles locales sont prises en charge : la vérification est donc disponible pendant que vous travaillez encore, et pas seulement après un déploiement. Le fonctionnement actuel est décrit dans la documentation.
La mise en place
Le serveur MCP est un paquet distinct du CLI, publié sous le nom de @testsprite/testsprite-mcp. Vous l'ajoutez aux paramètres MCP de votre éditeur avec une clé API issue du tableau de bord, et l'éditeur l'exécute comme sous-processus. Claude Code, Cursor, Windsurf, VS Code, GitHub Copilot et Trae le prennent tous en charge ; la configuration exacte diffère selon le client et se trouve dans la documentation d'installation MCP.
Par quoi commencer
Inscription, déconnexion, connexion. La panne totale la plus fréquente dans une application web générée.
Créer quelque chose et recharger. Sépare « l'écran s'est mis à jour » de « l'enregistrement existe ».
Le parcours principal depuis un deuxième compte. Détecte les hypothèses de permissions inscrites dans la propre session du développeur.
Le piège des trois états
Les applications web ont ceci de particulier qu'une même fonctionnalité peut se trouver dans trois états incohérents à la fois, et la plupart des bugs d'exécution sont un désaccord entre ces états.
Le serveur détient un enregistrement. Le navigateur en détient une copie en mémoire. Et l'utilisateur possède un modèle mental construit à partir de ce qu'il a vu un instant plus tôt. Une suppression qui retire l'enregistrement et la copie en mémoire mais laisse la ligne à l'écran donne un utilisateur convaincu que la suppression a échoué. Une sauvegarde qui met à jour l'écran mais pas le serveur produit l'inverse.
La conséquence pratique, c'est qu'une vérification qui ne regarde qu'un seul des trois ne prouve pas grand-chose. Poser une assertion sur l'écran juste après une action teste la copie du navigateur. Poser une assertion après un rechargement teste le serveur. Refaire l'action une deuxième fois teste si la première a laissé quelque chose derrière elle. Ces trois vérifications réunies couvrent l'essentiel de ce qui atteint réellement les utilisateurs, et aucune n'exige de lire le code.
Puis faites-le survivre à la session
Une connexion MCP couvre le moment de la modification. La non-régression exige que les mêmes vérifications tournent, que quelqu'un soit au clavier ou non.
La GitHub App est un webhook que vous configurez dans le tableau de bord TestSprite. Il écoute l'événement de déploiement que votre pipeline produit déjà, si bien que rien ne change dans votre dépôt.
GitHub Actions place l'étape à l'intérieur de votre propre workflow, configurée depuis le terminal. Les commandes actuelles se trouvent dans le dépôt du CLI.
Ce que TestSprite vérifie et qu'un diff ne peut pas vérifier
Il ouvre l'application en cours d'exécution et s'en sert, ce qui est le seul moyen de voir les trois défaillances ci-dessus. Un état résiduel après une interaction, un rendu qui ne rattrape jamais ses données et un comportement qui diffère pour un deuxième compte sont invisibles dans le code source et évidents à l'usage.
Comme la connexion se situe à l'intérieur de la boucle de l'agent, la vérification fait partie de la modification plutôt que de la suivre. L'agent crée le cas de test, l'exécute, lit l'écart et itère ; vous voyez le résultat plutôt que les allers-retours.
Vous obtenez au final un ensemble de parcours revérifiés à chaque modification, de sorte que l'hypothèse de permission ou le filtre obsolète ne peuvent pas revenir discrètement une fois terminée la session qui les avait mis au jour.
Faut-il lui donner mon code source ?
Non. Il pilote l'application en cours d'exécution via son interface et rend compte du comportement observé. Votre agent dispose déjà du code.
Peut-il tester un serveur de développement local ?
Oui pour les exécutions frontend, via un tunnel depuis votre machine. Les cibles locales purement backend nécessitent toujours une URL accessible.
Et les parcours qui exigent un vrai e-mail ou un vrai paiement ?
Utilisez les modes test et des comptes dédiés. Tout ce qui implique un effet de bord réel chez un tiers se traite mieux par une vérification manuelle délibérée.
Combien de vérifications faut-il pour une application web ?
Commencez par les trois ci-dessus, puis ajoutez-en une pour chaque bug que vous rencontrez réellement. Une couverture qui suit les défaillances réelles vaut mieux qu'une couverture visant un pourcentage.
Est-ce la même chose que le CLI ?
Mêmes capacités, point d'entrée différent. MCP convient au travail dans l'éditeur, le CLI convient aux scripts et aux pipelines.
Ouvrez l'application, ne vous contentez pas de la lire.
Une connexion MCP de test d'applications web permet à l'agent de trouver les états résiduels, les rendus qui précèdent les données et les problèmes de deuxième compte qu'aucun diff ne révèle. Couvrez d'abord la connexion, la persistance et un deuxième compte, puis laissez les vérifications s'exécuter après la fin de la session.