Mon Agent IA a Échoué 30 Fois sur le Même Clic LinkedIn. Camoufox l'a Réussi du Premier Coup.

Parfois, l'IA fait juste n'importe quoi. Peu importe comment vous la promptez.

Le Même Clic, 30 Fois

Mon agent a échoué le même clic LinkedIn 30 fois, tapant le même bouton sur la même page dans une boucle de retry infinie. Les profils LinkedIn affichent "Suivre" comme action principale et "Se connecter" caché dans un menu overflow "Plus" (les 3 points). Vous tapez sur l'overflow, le menu apparaît, vous cliquez "Se connecter", la boîte de dialogue de connexion s'ouvre. Simple.

Le Chrome MCP prend une capture d'écran pour lire la position de l'élément, puis envoie le clic. Cette séquence a un délai. Court, mais incompressible. Au moment où l'événement de clic se déclenche, le menu overflow animé s'est déjà fermé tout seul. L'agent ne le détecte pas. Il prend une autre capture d'écran, ne voit pas de dialogue "Se connecter", reboucle. À la tentative 14, les logs montrent exactement la même séquence. La tentative 20 n'est que du bruit.

À un moment donné, je suis là à lire les logs en me disant que ce truc va me faire bannir. (Énergie Dark Souls : vous êtes mort, vous avez essayé, vous êtes mort encore. Sauf que se faire bannir de LinkedIn n'est pas une situation de respawn.)

Le Chrome MCP n'est pas un mauvais outil. Je veux être précis là-dessus avant d'aller plus loin, parce qu'il est facile de spiraler vers "l'outil craint" après une session comme ça. Pour 80% des tâches d'automatisation de navigateur, c'est le bon choix par défaut. Le problème était que le cas du menu overflow LinkedIn n'était pas dans ces 80%, et le signal pour changer était déjà là à la tentative 2.

Ce Que Chrome MCP Fait Vraiment Bien (Les 80%)

Réutiliser une session existante, c'est là où Chrome MCP est imbattable. Le navigateur est déjà authentifié, cookies chargés, 2FA validée. L'agent se glisse dans ce contexte sans toucher aux flux de connexion ou de vérification.

La navigation et l'extraction de texte sont fiables. Lire le contenu DOM, scraper des pages structurées, extraire du texte de mises en page stables : solide.

Les formulaires HTML standard fonctionnent proprement. Champs de texte, listes déroulantes, cases à cocher : le MCP les remplit sans cérémonie, pas de gymnastique JavaScript requise.

Le débogage frontend est le cas sous-estimé. L'agent peut lire les erreurs console, la cascade réseau, et l'état de page en direct. Utile quand vous construisez quelque chose et voulez que l'agent vérifie sa propre sortie dans le navigateur sans lancer un harnais de test séparé. Pensez-y comme du pair programming où 1 partenaire ne communique que par captures d'écran. Inefficace pour la plupart des conversations, étonnamment correct pour la revue de code.

Ces 4 cas couvrent la majorité de ce dont tout workflow d'automatisation de navigateur a besoin au quotidien. Les cas limites surgissent quand l'action nécessite un timing serré ou une gestion d'événements natifs.

Les 4 Façons Dont Ça Casse

Le cas LinkedIn a produit 4 modes de défaillance distincts sur la même action. Chacun se joue différemment.

Le menu se ferme avant que le clic n'arrive. L'overhead entre prendre une capture d'écran et dispatcher le clic est incompressible. Pour une transition CSS qui se ferme en 150ms, cet overhead suffit. Le menu a disparu avant que le clic n'arrive.

Les clics synthétiques sont silencieusement ignorés. La bibliothèque de composants artdeco de LinkedIn écoute les événements de pointeur de confiance, le genre généré par une vraie saisie matérielle. Un clic dispatché programmatiquement ne porte pas le flag isTrusted. Le composant ne répond pas. Pas d'erreur, pas de feedback, rien.

L'élément est caché par l'en-tête sticky. La navbar de LinkedIn reste fixée en haut du viewport. Si le menu overflow s'ouvre près du haut de la page, la navbar intercepte le clic. Chrome MCP n'effectue pas de hit-test pour détecter ça.

L'onglet dérive. Après assez de clics parasites, quelque chose s'active : une carte, un lien de profil, un panneau de sidebar. L'agent perd la page cible et commence à automatiser avec confiance ce sur quoi il a atterri. (Événement de networking sponsorisé accepté. Merci, agent.)

Chacun de ces cas est gérable en isolation. Les 4 ensemble sur la même action, c'est un mur structurel.

Pourquoi Ça Casse (Ce N'est Pas le Prompt)

Le Chrome MCP opère depuis au-dessus du navigateur. Il se pose comme une extension, observe par captures d'écran, dispatche 1 action par cycle, et attend. Ce modèle a un vrai avantage : il ne nécessite pas d'installer quoi que ce soit dans le moteur de rendu, il réutilise votre session Chrome existante sans modification, et vous pouvez le pointer vers n'importe quelle instance Chrome en cours sans setup. Le compromis est que chaque action implique un aller-retour avec assez de latence pour faire tomber les états UI sensibles au temps, et les clics qu'il dispatche ne proviennent pas du pipeline d'événements de confiance.

Les frameworks JavaScript modernes vérifient la propriété isTrusted sur les événements de pointeur entrants, et React, Vue, et les bibliothèques de composants comme artdeco de LinkedIn font toutes cette vérification. Un clic Chrome MCP atterrit dans le DOM mais échoue à la validation interne du composant. L'échec est silencieux, aucune erreur ne remonte, et vous devriez lire le source du composant pour même savoir que la vérification existe.

J'ai passé 3 semaines à essayer de corriger spécifiquement le côté timing : wait_for_element, augmenter les gaps de retry, différentes valeurs de délai entre capture d'écran et clic. Le menu continuait de se fermer. Le problème isTrusted était complètement séparé et je ne l'ai compris qu'après avoir lu le source artdeco. Ça a été un jeudi amusant.

Why CLIs often beat MCP for agent work couvre le côté coût en tokens de ce compromis, mais le côté événement de confiance est ce qui mord vraiment en production.

Un clic Chrome MCP est techniquement un clic. Le composant le traite comme un email poli que personne n'a demandé.

Le Signal de Changement : 2 à 3 Échecs

La règle tient en 1 ligne : après 2 à 3 échecs sur la même action spécifique, arrêtez et changez d'outils. Ajouter une autre boucle de retry ne change pas le résultat quand l'échec est structurel.

Après la 3ème tentative échouée sur le même geste, vous ne déboguez plus l'approche. Vous montez en niveau votre fichier de log.

Les situations qui déclenchent le changement :

• Un menu ou overlay se ferme avant que le clic n'arrive
• 2 gestes doivent s'enchaîner dans une fenêtre de temps serrée (ouvrir menu, puis cliquer élément)
• L'élément ne répond pas aux clics et ne montre aucune erreur
• Un bouton React ou Vue reste grisé malgré le formulaire qui semble valide
• La même action doit tourner des dizaines de fois en mode headless

Je pense que ce seuil de 2-à-3 tient pour la plupart des UI web standard. Moins confiant qu'il s'applique de la même façon aux frameworks entièrement custom où les modes de défaillance semblent différents.

Ce Que Camoufox Change (Et Ce Que Ça Coûte)

Camoufox est un navigateur Firefox durci contre la détection de bots, piloté par Playwright. Là où Chrome MCP opère depuis au-dessus du navigateur, Playwright injecte les événements depuis l'intérieur du moteur de rendu, par le même chemin que prend la vraie saisie utilisateur.

Sur le cas overflow LinkedIn :

Vrais événements de confiance. Playwright dispatche la chaîne complète d'événements de pointeur avec isTrusted: true. Le menu overflow s'ouvre. L'élément "Se connecter" enregistre le clic. Premier profil terminé.

Localisateurs basés ARIA. Au lieu de coordonnées pixel de capture d'écran : page.getByRole('menuitem', { name: 'Connect' }). Déterministe, lisible, et ne casse pas quand LinkedIn ajuste leur padding de 2 pixels dans une fenêtre de maintenance lundi. Toutes les équipes ont eu ce déploiement 😅

Pas d'aller-retour entre actions. Ouvrir le menu et cliquer l'élément dans la même exécution de script. Pas de cycle de capture d'écran entre les 2 étapes. Pas de race condition.

Validation d'état React. Pour un bouton submit qui reste grisé jusqu'à ce que l'input ait une valeur : Playwright émet à la fois les événements input et change pour réveiller l'état du composant, puis clique le bouton déverrouillé. Chrome MCP clique le bouton grisé. Rien ne se passe.

Réserves tout de suite. La session ne se transfère pas : le premier lancement nécessite une connexion manuelle, puisque Camoufox n'hérite pas des cookies de Chrome. Une nouvelle empreinte de navigateur déclenche la vérification "nouvel appareil" de LinkedIn. Le script Playwright est du code de production qui doit être maintenu. Et la limitation de débit de LinkedIn se fiche de quel navigateur vous utilisez si la cadence d'action semble automatisée.

Le changement a un vrai coût de setup. Il paie quand Chrome MCP a déjà montré 2 à 3 échecs sur une action spécifique. Pas avant. Playwright est construit sur Chrome DevTools Protocol, ce qui fait partie de pourquoi le modèle d'événement finit beaucoup plus proche de la vraie saisie utilisateur que tout ce qui opère depuis au-dessus du navigateur.

Quand Utiliser Quoi

Chrome MCP pour :

• Tâches ponctuelles rapides sur des sites où vous êtes déjà connecté
• Lire du contenu depuis des pages stables
• Remplir des formulaires sur des inputs HTML standard
• Déboguer des problèmes frontend dans une session existante

Camoufox + Playwright pour :

• Actions répétées qui doivent être fiables
• Éléments interactifs qui nécessitent des événements de confiance
• Séquences de timing serré (menus, dropdowns, modales)
• Automatisation de production qui ne peut pas se permettre de boucles de retry

Le déclencheur de changement : 2-3 échecs sur la même action spécifique. Pas 30.

---

La session de 30 tentatives a coûté 40 minutes et une réécriture de script Playwright. Camoufox a eu le premier profil en 12 secondes. Les 29 suivants ont tourné au même rythme.

Le signal était là à la tentative 2. J'avais juste besoin de 28 tentatives de plus pour le lire. 🤦‍♂️

Sources

• Camoufox : navigateur Firefox durci pour l'automatisation, construit sur Playwright
• Documentation Playwright : bibliothèque d'automatisation de navigateur
• Chrome DevTools Protocol : spécification CDP officielle

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission. Ça ne vous coûte rien, et ça m'aide à continuer de livrer des articles de qualité chaque jour pour votre plaisir de lecture.