RepoIntermediate

Watch : l'utilisateur robot qui teste ton app et te prévient avant tes clients

Il existe un angle mort entre « mon code est bon » et « mon app fonctionne pour un vrai utilisateur ». Dans ce creux vivent mille choses que tes tests ne voient pas : un CDN tombé, une variable mal configurée en production, un bouton dont le texte a changé et qui a cassé le login, un écran qui met soudain 8 secondes à charger. Tu l'apprends quand un client se plaint… ou quand il s'en va sans rien dire. Watch comble ce creux : c'est un utilisateur robot qui parcourt tes parcours critiques dans un vrai navigateur, comme une personne, et te prévient à la seconde où quelque chose casse ou ralentit — et pas seulement l'alarme : il t'apporte l'étape exacte qui a échoué, le screenshot et le correctif. C'est gratuit, ça vit sur GitHub, et je t'explique ici quand l'utiliser et comment le mettre en place.

Jun 25, 202612 min

Pour qui c'est ?

Pour quiconque a une app ou un site en ligne et veut dormir tranquille — même sans savoir programmer. Si un jour tu as appris que ton propre site était en panne parce qu'un client t'a écrit, c'est pour toi. Watch est un gardien robot qui teste ton app à intervalles réguliers, comme le ferait un utilisateur, et te prévient en premier. Tu le configures une fois en langage naturel ; le reste se fait tout seul.

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.

Imagine-le comme ça

Tes tests, c'est comme vérifier les plans d'un immeuble : ils confirment que la conception est correcte. Watch, c'est l'inspecteur qui entre vraiment, prend l'ascenseur, ouvre les portes et allume les lumières. Les plans peuvent être parfaits et l'ascenseur en panne. Watch trouve l'ascenseur en panne — parce qu'il l'utilise.

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 :

Ce qui arrive sans gardien

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.

Le coût caché

Un utilisateur qui tombe sur ton app cassée te prévient rarement. Il s'en va. Pour chaque client qui se plaint, il y en a des dizaines qui ferment simplement l'onglet et ne reviennent pas. Le dommage d'un parcours cassé ne se mesure pas en tickets de support — il se mesure en gens que tu as perdus sans jamais savoir pourquoi.

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) :

Les parcours critiques de l'habitude

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.

Le facteur différenciant de Watch

Comme Sentinel, Watch ne se contente pas de « le parcours a échoué, bonne chance ». Il te dit quelle étape a échoué, te donne le screenshot du moment exact, et te propose le correctif. Exemple réel : « l'étape 4 (cliquer sur Se connecter) a échoué parce que le bouton s'appelle désormais Entrer → change le texte attendu, une ligne ». Pas seulement l'alarme : la cause et le remède.

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.

Le moteur : agent-browser, pas de magie

Watch s'appuie sur agent-browser, un vrai outil qui donne à l'IA un véritable navigateur pour naviguer comme une personne (pas Playwright, pas un service payant externe). Si tu as déjà vu la ressource sur agent-browser, c'est cette puissance appliquée à la surveillance de ton app 24/7.

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 :

bash

/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.

Le plus simple : demande-le en langage courant

Après l'avoir installé, tu dis à ton IA : « lance Watch sur mon app et dis-moi si quelque chose a cassé » ou « mon login et mon checkout fonctionnent-ils toujours ? ». Et pour la surveillance récurrente, tu la programmes avec une routine (/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 :

Surveiller la santé de mon app avec Watchtext

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

Ce que l'agent fait tout seul

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.

Ce que tu fais, toi (une fois)

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.

Honnêteté : read-only et non destructif

Watch navigue et observe : il n'efface pas de données, ne fait pas d'achats réels, n'envoie pas de formulaires irréversibles — sauf si tu marques explicitement un parcours comme sûr et en sandbox. Et comme l'analyse est faite par ton agent d'IA, le contenu est traité là où tourne cet agent. Watch n'envoie ni tes captures ni tes données à un service de monitoring tiers.

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 :

MentexDev/neuralos-watch

REPO

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.

MarkdownMITView on GitHub

Chez NeuralOS…

Watch est le deuxième des gardiens : de petits alliés d'IA qui surveillent ton produit et proposent le correctif, sans jamais rien toucher seuls. Sentinel veille sur le code de l'intérieur ; Watch veille à ce que l'app fonctionne de l'extérieur, pour un vrai utilisateur. La vision : que ton produit se surveille lui-même et te prévienne en premier.