L'agent IA écrivait le test. Maintenant, il le lance aussi.

Le problème

Claude Code, Cursor et les autres agents de code écrivent des tests Cypress corrects la plupart du temps. Ils ne peuvent pas les exécuter. Le développeur lançait donc la commande, attendait, copiait la sortie dans la conversation, et recommençait à chaque correction.

Cette boucle manuelle coûtait plus que le test lui-même. Et l'agent travaillait sur une sortie tronquée : pas de capture d'écran, pas de contexte autour de la ligne qui casse, aucune différence entre un test cassé et un test instable.

Nos équipes maintiennent des suites de bout en bout sur des produits en production. Il fallait que l'agent puisse prouver lui-même qu'une fonctionnalité marche, avec les mêmes garde-fous qu'un ingénieur.

Ce que nous avons fait

Nous avons écrit un serveur MCP (Model Context Protocol) en TypeScript qui expose Cypress à l'agent sous forme de douze outils : lancer une spec, lancer un seul test par son nom, rejouer la dernière exécution, lire le contexte d'un échec, retrouver une capture, cartographier la suite et diagnostiquer l'installation.

Chaque réponse suit la même enveloppe JSON : un statut, un résumé d'une ligne, les données, et l'action suivante recommandée. L'agent ne déchiffre pas un terminal. Il lit un résultat structuré qui inclut le nombre de tentatives de chaque test. Un test qui échoue puis passe au réessai est marqué instable, selon la même règle que Cypress Cloud.

La sécurité est une exigence, pas une option. Cypress est lancé sans shell, si bien qu'un nom de test contenant « & » ne peut pas exécuter de commande sous Windows. Un chemin de spec qui sort du projet est refusé. La clé d'enregistrement Cypress Cloud reste dans l'environnement du serveur et ne passe jamais par l'agent.

Le serveur complète le Cypress Cloud MCP officiel au lieu de le concurrencer. Le nôtre exécute les tests en local, celui de Cypress lit l'historique enregistré. Une exécution lancée avec l'option d'enregistrement renvoie l'URL du run, que les outils Cloud acceptent directement. Un test automatisé garantit qu'aucun de nos noms d'outils n'entre en collision avec les leurs.

Où cela en est

cypress-mcp est publié sur npm et sur GitHub. Il comptait environ 450 téléchargements par semaine sur npm à la mi-octobre 2026, sans campagne de promotion.

Depuis la version 0.2.0, en octobre 2026, il est sous licence Apache 2.0, usage commercial et intégration continue compris. La décision est venue d'une équipe d'ingénierie qui voulait l'adopter et vérifiait d'abord les conditions. Nous préférons qu'un outil soit utilisé plutôt que négocié.

Chaque modification passe une CI sur Windows, macOS et Linux avec Node 22 et 24, une analyse CodeQL, et une suite de bout en bout qui pilote un vrai projet Cypress, en version 14 et en dernière version, par le protocole MCP, exactement comme le ferait un agent. Cette suite tourne aussi chaque semaine, pour qu'une nouvelle version de Cypress qui casse quelque chose soit détectée par nous avant d'être subie par les utilisateurs.

Nous ne publions ni nombre d'utilisateurs ni gain de temps chiffré. npm compte des téléchargements, pas des équipes, et nous n'avons pas de mesure contrôlée du temps économisé.