Un marketeur a construit un moniteur IA de la concurrence : il repère les fonctionnalités discrètes et ne s'affole pas à chaque déploiement

Les changements les plus intéressants dans les produits des concurrents, personne ne les annonce. Une nouvelle automatisation ou un assistant IA est simplement activé pour les utilisateurs, sans communiqué de presse ni mention dans le store. Vladimir Mikhaïlov, Marketing Analyst chez Garage Eight, a décidé de repérer ce genre de choses automatiquement. Son expérience sera utile à tous ceux qui ont tenté de bâtir une surveillance avec Playwright et se sont noyés sous les fausses alertes.

Pourquoi la comparaison du DOM ne fonctionne pas

La première idée est évidente : capturer le HTML aujourd'hui, le capturer demain, comparer. Sur une SPA moderne, cela donne un détecteur de déploiements front-end, pas de changements produit. Une classe CSS change, un testid, l'adresse d'une section, un composant est déplacé, un bouton renommé, ou l'utilisateur voit une autre variante d'un test A/B. Cela fait des centaines d'alertes par jour, presque toutes inutiles.

L'auteur a changé la question elle-même. Non pas « qu'est-ce qui a changé sur la page », mais « que peut faire l'utilisateur maintenant qu'il ne pouvait pas faire avant ». D'où la décision architecturale clé : le LLM ne reçoit pas deux fichiers HTML avec la consigne « trouve la différence ». Le modèle intervient plus tôt, en entrée : il explore l'interface et construit un modèle structuré du produit. La comparaison des deux modèles est faite par du Python déterministe. Le résultat est stable et reproductible, et ne dépend pas de l'humeur du modèle.

Un exemple tiré de l'article. Une fonction est passée de /analytics à /insights/analytics, le DOM a été réécrit, l'utilisateur n'a rien remarqué. Un diff structurel hurlera « MAJOR CHANGE ! ». Mais si l'URL et le nom restent identiques et qu'une planification d'exécution automatique s'ajoute à l'action manuelle, le diff reste muet, alors qu'il s'agit d'un changement important. C'est pourquoi chaque fonction conserve une liste de capabilities : schedule_action, export_report, create_custom_alert. Un hash distinct est calculé pour elles, et c'est lui qui signale un changement de fond.

Pipeline et deux interfaces

La chaîne est la suivante : navigateur avec session authentifiée, AI Discovery, modèle de fonctions, instantané sémantique, comparaison, filtre de pertinence métier, Slack. Le site public n'est qu'une vitrine. Saved Views, Custom Alerts, Automation Rules et recommandations ne sont visibles qu'après connexion ; le système parcourt donc le produit comme un utilisateur connecté ordinaire.

Une couche analytique s'y ajoute. Claude est relié via MCP à l'historique de surveillance avec des outils en lecture seule : fonctions actuelles des concurrents, NEW/UPDATED/REMOVED sur une période, filtres par catégories, vérification de la couverture. Cela donne deux modes. Slack envoie les changements de lui-même. Et à la question « qu'est-ce qui est apparu chez les concurrents en un mois et que les autres n'ont pas ? », l'analyste obtient une réponse en langage naturel, sans SQL ni JSON. L'historique est en outre synchronisé avec Google Drive comme base de connaissances pour un Claude Project distinct.

Authentification : là où l'automatisation casse

Une grande partie de l'article est consacrée à la façon de ne pas échouer à la connexion. Les trouvailles pratiques :

• Des états plutôt qu'une vérification d'URL. La condition « l'adresse ne contient pas /login » n'est pas fiable : une SPA peut afficher une page une seconde puis rediriger aussitôt vers une autre. L'auteur utilise une machine à états (AUTH_OK, AUTH_EXPIRED, AUTH_2FA_REQUIRED, AUTH_CAPTCHA_REQUIRED, AUTH_UNKNOWN) et considère l'utilisateur comme authentifié si au moins deux marqueurs indépendants sur trois sont trouvés, par exemple le menu utilisateur et le bouton de déconnexion.
• Une erreur de navigation n'est pas un échec de connexion. L'exception « Execution context was destroyed » lors d'une connexion réussie peut provoquer un nouvel envoi du formulaire. L'état est vérifié par une série de mesures, et les erreurs temporaires sont ignorées.
• Les secrets n'arrivent pas au modèle. Identifiant et mot de passe sont stockés dans le coffre système, et c'est un processus Playwright standalone distinct qui les saisit. L'IA reçoit seulement le signal que la session est de nouveau active, et l'historique des requêtes au modèle ne contient aucun secret.
• La 2FA n'est pas contournée. Si un SMS arrive, le système s'arrête et attend un humain. Après saisie du code, la session est enregistrée et les lancements suivants se font seuls.
• Toutes les captchas ne se valent pas. Un badge reCAPTCHA invisible sur la page ne signifie pas qu'on vous demande de passer une vérification. Il faut distinguer « la captcha existe » de « la captcha bloque la connexion ».
• Profil persistant ne veut pas dire session persistante. Un service émettait un cookie d'authentification avec expires: -1, qui mourait avec le processus Chrome. L'auteur n'a pas lutté contre cela : après l'autologin, le navigateur reste ouvert, et Playwright MCP s'y connecte via CDP (connectOverCDP).

Ce qu'il faut retenir, et les limites

Trois idées transposables. Première : utilisez le LLM pour transformer le chaos en structure, mais comparez avec du code déterministe. Deuxième : décrivez le produit par les actions de l'utilisateur, pas par le balisage. Troisième : considérez les secrets comme une zone où le modèle n'entre jamais.

Il existe aussi des limites. Dans la partie accessible du matériel, il n'y a pas de chiffres : combien coûte une exécution, à quelle fréquence le modèle manque ou invente des fonctions, comment le filtre de pertinence distingue l'important du détail. Se connecter aux produits d'autrui avec un compte peut enfreindre les conditions d'utilisation du service, et il faut le vérifier avec des juristes avant le lancement. L'architecture elle-même semble viable et convient à la veille produit dans n'importe quelle équipe.