1. Le moment : quand « les tests sont passés » ne veut pas dire « ça fonctionne »
Le moment arrive le jour où tu découvres une vérité inconfortable : que ton code soit « bon » ne garantit pas que ton app fonctionne. Tu l'as lancée, les tests sont passés au vert, le déploiement était parfait. Et pourtant, un utilisateur n'arrive pas à se connecter. Comment ? Parce qu'entre ton code et ton utilisateur, il y a tout un monde de choses qu'aucun test de ton dépôt ne voit : le serveur, le réseau, une configuration de production, une API externe lente, une modification de dernière minute.
C'est là qu'intervient Watch : quand tu comprends qu'il te faut quelqu'un qui teste vraiment l'app, de l'extérieur, comme un vrai utilisateur — qui ouvre le navigateur, saisit ses identifiants dans le login, clique sur le bouton, vérifie que l'écran suivant charge. Pas qui relit le code : qui utilise l'app. Ça s'appelle le monitoring synthétique, et Watch le fait à ta place.
2. La douleur : tu l'apprends par le client, et c'est déjà trop tard
La douleur est honnête et silencieuse. Elle n'est pas dramatique — c'est pire : elle est invisible jusqu'à ce qu'elle te coûte des utilisateurs. Les symptômes :
- Le login casse à 3h du matin et tu l'apprends à 9h, quand arrive le premier mail d'un client furieux.
- Un changement de copie (« Se connecter » → « Entrer ») casse un parcours automatisé sans que personne ne le remarque.
- Un écran commence à mettre 8 secondes ; les utilisateurs ne se plaignent pas, ils s'en vont, tout simplement.
- Une API externe échoue et la moitié de l'app cesse de fonctionner, mais ton monitoring ne regarde que « si le serveur répond » (et il répond… avec une page cassée).
Le problème de fond : les monitors traditionnels vérifient seulement « le serveur est-il vivant ? ». Mais un serveur peut être bien vivant en servant une page cassée. La seule façon de savoir si ton app fonctionne, c'est que quelqu'un l'utilise. Et si ce quelqu'un est toujours un vrai client qui découvre la panne, tu as déjà perdu.
3. L'habitude : surveiller est CONSTANT, pas un contrôle unique
Voici ce qui change ton comportement : Watch n'est pas un test que tu lances une fois avant de mettre en ligne. C'est une ronde de surveillance qui se répète. Tu lui dis de surveiller tes parcours critiques à intervalles réguliers (toutes les 15-30 minutes, par exemple) et de comparer chaque passage au précédent. Ce qui hier fonctionnait en 2 secondes et met aujourd'hui 8 secondes, il le détecte. Ce qui hier passait et échoue aujourd'hui, il le détecte.
Les parcours qu'il vaut TOUJOURS la peine de surveiller (ceux qui, s'ils cassent, te font perdre de l'argent ou des utilisateurs) :
- Login — si personne n'entre, ton app est en panne pour ceux qui sont déjà clients.
- Inscription — si personne ne s'inscrit, tu cesses de croître (et de rentabiliser des campagnes déjà payées).
- Le parcours qui te fait vivre — ce que l'utilisateur VIENT faire (créer quelque chose, publier, acheter).
- Checkout / paiement — s'il casse, tu perds des revenus en silence.
4. Comment ça marche, en 3 pièces simples
Pas besoin de comprendre le code pour saisir le principe. Watch travaille en trois étapes :
1) Tu décris tes parcours une fois. Dans un fichier simple (flows.json), tu listes les chemins critiques : « ouvre /login, saisis l'email, saisis le mot de passe, clique sur Se connecter, vérifie que tu arrives au tableau de bord ». Sans mots de passe réels écrits là-dedans — on utilise des variables sécurisées.
2) Watch les parcourt comme un utilisateur. Il utilise agent-browser (un vrai navigateur piloté par l'IA) pour faire exactement ça : il ouvre, saisit, clique, attend, regarde. Il mesure le temps de chaque étape et capture des écrans.
3) Il compare avec la dernière fois où tout allait bien. Une étape qui fonctionnait avant échoue-t-elle maintenant ? Un parcours qui mettait 2s met-il désormais 8s ? Il ne te prévient que de ce qui a vraiment changé — pas de spam avec la même alarme cent fois.
5. Comment l'installer : une commande
Watch est une skill pour Claude Code. Elle s'installe en une commande et a besoin d'agent-browser comme moteur du navigateur :
/plugin marketplace add MentexDev/neuralos-watch /plugin install neuralos-watch@neuralos-watch # Le moteur du navigateur (une fois) : npm i -g agent-browser && agent-browser install
Un autre assistant ? Ça marche aussi avec npx skills add MentexDev/neuralos-watch. Ensuite tu copies le fichier d'exemple de parcours, tu l'adaptes à ton app, et tu parles normalement à ton IA.
/schedule) pour qu'elle tourne toute seule à intervalles réguliers. Honnêteté : ce n'est pas un service magique qui tourne seul pour toujours — c'est ton agent, qui exécute tes parcours, à l'horaire que tu décides.6. Le prompt prêt à copier
Le voici de bout en bout. Colle-le dans ton agent (Watch déjà installé), remplis les [crochets] et laisse la Vigie faire sa ronde :
Je veux que tu utilises la skill neuralos-watch pour vérifier la santé de mes parcours critiques, en mode read-only et NON destructif (n'efface pas de données et ne fais pas d'achats réels). URL de mon app (pointe vers staging/tests, pas vers la production avec des données de clients) : [https://staging.miapp.com] Parcours critiques à surveiller : [ex. 1) que le home charge · 2) login avec email+mot de passe → arrivée au tableau de bord · 3) créer un nouveau projet] Identifiants de test : utilise les variables d'environnement [WATCH_TEST_EMAIL / WATCH_TEST_PASSWORD], jamais de mots de passe écrits ici. Suis la procédure de Watch : aide-moi à définir le flows.json si je ne l'ai pas, parcours chaque flux avec agent-browser, mesure les temps, et remets-moi un rapport. Pour chaque problème : l'étape exacte qui a échoué, le screenshot, ce qui était attendu vs ce que tu as trouvé, et le correctif proposé. Signale aussi ce qui a ralenti même sans avoir cassé. Si c'est le premier passage, établis la baseline (ne compare pas encore). N'exécute AUCUNE étape destructive ou de paiement sauf si elle est marquée comme sûre et en sandbox.
7. Le chemin facile : qui fait quoi
- Parcourir tes flux dans un vrai navigateur, étape par étape, comme un utilisateur.
- Mesurer les temps, capturer les écrans et détecter les requêtes réseau échouées.
- Comparer avec le dernier passage réussi et t'écrire le rapport avec le correctif.
- Décrire tes parcours critiques dans le fichier d'exemple (ou demander à l'IA de t'aider à le faire).
- Pointer vers un environnement de tests, pas vers la production avec des données réelles de clients.
- Programmer la routine (/schedule) si tu veux une surveillance automatique récurrente.
8. Le dépôt (gratuit, MIT, mets une étoile)
Watch est open source et gratuit. S'il t'a prévenu d'une casse avant tes utilisateurs, laisse-lui une étoile :
Un utilisateur robot qui parcourt tes parcours critiques dans un vrai navigateur avec agent-browser et te prévient quand l'un d'eux casse ou ralentit — avec l'étape, le screenshot et le correctif. Read-only par défaut.