Comment P2ER a créé un environnement de confiance pour le codage agentique avec les Outils pour les développeurs Chrome pour les agents

Peer Weidner
Peer Weidner
GitHub LinkedIn
José Luis Zapata

Publié le 22 juin 2026

P2ER, une agence de solutions numériques, utilise les Outils pour les développeurs Chrome pour les agents afin de s'assurer que seuls les logiciels fonctionnels et validés sont transmis aux humains pour examen final. En transformant leur workflow en infrastructure agentique, ils ont permis aux agents IA d'effectuer une vérification empirique de l'UI, ce qui a augmenté la fréquence de déploiement, qui est passée d'une fois par semaine à plusieurs fois par jour.

Le défi : améliorer la qualité dans les applications existantes

P2ER propose des expériences numériques haut de gamme pour des marques internationales, y compris des constructeurs automobiles, des marques horlogères et des entreprises hôtelières. Comme pour de nombreuses entreprises, leur principal défi était de travailler dans des applications existantes complexes. L'équipe qui a adopté le codage agentique a rencontré trois principaux obstacles :

  • Tests d'UI fragiles : Les suites de tests standards ont rencontré des difficultés avec les données dynamiques, telles que les fluctuations des prix des hôtels ou les offres saisonnières dans certains projets de P2ER. Les données fictives masquaient souvent des failles d'intégration qu'un testeur humain aurait immédiatement détectées.
  • Problèmes de fiabilité de l'agent. Sans instructions explicites, les agents d'IA affirmaient parfois qu'une tâche était terminée sans l'avoir réellement vérifiée.
  • Perte de contexte : Les tâches générales et les délais d'expiration des modèles ont fait perdre aux agents le fil des objectifs de session. Les développeurs ont donc eu du mal à suivre et à poursuivre le travail qu'un agent avait commencé.

La solution : créer une infrastructure pour l'artisanat

P2ER a créé une infrastructure qui traite l'IA comme un "partenaire d'entraînement" capable de gérer également les aspects répétitifs du développement. Cette approche permet à l'équipe de développer son savoir-faire en se concentrant sur l'architecture et la résolution créative de problèmes.

Appliquer la validation empirique avec les outils de développement pour le serveur MCP des agents

Pour assurer la fiabilité, le P2ER a établi une règle de validation empirique obligatoire. Ce mandat d'ingénierie, codifié dans le fichier AGENTS.md du projet, stipule :

All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.

Au lieu de se fier à la parole de l'agent, l'équipe utilise les outils pour les développeurs Chrome afin de fournir aux agents un environnement sûr pour naviguer dans l'application de manière visuelle et interactive.

Ces "agents de test" effectuent plusieurs tâches clés que les tests statiques standards ne détectent pas :

  • Test des données dynamiques : même dans un environnement de préproduction, les agents testent des données réelles et fluctuantes (comme les prix des hôtels qui varient selon les saisons) pour découvrir l'application exactement comme le ferait un utilisateur. Cela est possible grâce aux outils d'interaction des agents dans les outils de développement, tels que new_page, navigate_page, fill, click et hover, mentionnés dans leur compétence github-issue-test. L'agent peut ainsi s'authentifier de manière dynamique et simuler un parcours utilisateur réaliste.
  • Audits visuels : les agents identifient les différences visuelles entre les mises en page Figma et l'implémentation réelle. En utilisant l'outil take_screenshot de la console d'outils de développement pour les agents, la compétence figma-validate capture des captures d'écran haute résolution des rendus Storybook en direct pour effectuer une comparaison côte à côte avec les exportations Figma.
  • Contrôles d'usabilité : les agents détectent les traductions manquantes ou les erreurs d'usabilité que les scripts automatisés ne voient souvent pas. En interagissant directement avec l'arborescence d'accessibilité et en examinant les instantanés visuels récupérés via take_snapshot et take_screenshot, les agents recherchent activement les anomalies d'UI telles que les chaînes MISSING_MESSAGE, comme indiqué explicitement dans leurs workflows de validation automatisés.

Décomposer et rendre persistantes les sous-tâches

Pour lutter contre les délais d'expiration des sessions et la perte de contexte, P2ER compartimente strictement le travail à l'aide de sous-agents. Il demande ensuite à ses agents d'agir comme des orchestrateurs de cette manière :

Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.

Pour tenir les responsables produit humains informés de ce processus, l'équipe a intégré une compétence personnalisée permettant aux agents de suivre leur travail dans les problèmes GitHub. Cela garantit que chaque tâche de sous-agent et ses résultats sont conservés et documentés en tant que sous-problème à l'aide de l'API GitHub, ce qui crée une piste d'audit claire et un contexte persistant que d'autres développeurs peuvent reprendre.

Isoler les environnements pour l'exécution parallèle

Pour faire évoluer leur processus de développement afin que plusieurs agents exécutent du code en parallèle, P2ER exige des environnements isolés par tâche pour ses agents. Cela permet d'éviter les conflits d'état et les problèmes de réseau lors de la validation de l'UI.

La configuration technique de cet isolement comprend les éléments suivants :

  • Worktrees Git isolés : pour éviter les conflits de fichiers et la pollution de l'espace de travail lorsque plusieurs agents fonctionnent en parallèle, les tâches sont exécutées dans des worktrees Git isolés. Chaque agent dispose d'un espace de système de fichiers dédié où les variables d'environnement sont copiées et les dépendances sont liées symboliquement, ce qui garantit que les modifications de fichiers ne s'écrasent jamais les unes les autres.
  • Environnements uniques : chaque agent et chaque tâche exécutent leur serveur de développement Next.js sur un port isolé unique. Conformément aux règles du projet, les serveurs sont démarrés de manière dynamique avec npx next dev -p <custom_port> --turbopack pour assurer une exécution parallèle sans conflit réseau.
  • Clones de base de données : pour éviter les collisions de données lors des tests parallèles, le programme P2ER duplique la base de données principale dans un schéma spécifique à la tâche au démarrage de l'agent. Une fois que l'agent a terminé sa vérification et que la tâche est approuvée, un processus de nettoyage automatisé supprime la base de données isolée. Ce cycle de vie garantit que chaque agent fonctionne dans un espace de travail propre et ne laisse aucune donnée inutilisée.
  • Tests ciblés : tous les tests de navigateur effectués via les Outils pour les développeurs Chrome pour les agents doivent cibler le port personnalisé exact attribué à cette instance d'agent spécifique. Leur mandat de test interdit le codage en dur des ports par défaut, ce qui nécessite des URL cibles de test telles que http://localhost:<custom_port>.

Impact : multiplication par 10 de la vitesse de développement tout en conservant la qualité

Le passage au codage agentique avec des garde-fous de confiance élevée a transformé le résultat de P2ER. Ces modifications étaient initialement nécessaires pour garantir la fiabilité de l'agent, mais elles ont également profité à l'ensemble du cycle de vie du développement :

  • Des cycles de travail 10 fois plus rapides : la plupart des problèmes sont désormais résolus en une seule journée, contre une moyenne de 1 à 3 jours auparavant. La fréquence de déploiement est passée d'une fois par semaine à plusieurs fois par jour.
  • Concentration stratégique pour les équipes QA : les agents détectant désormais les régressions de base et les "problèmes faciles à résoudre", l'équipe de test humaine peut se concentrer sur des scénarios de test plus complexes et approfondis.
  • Implémentations robustes pour les parties prenantes : les implémentations sont désormais plus résilientes, car les tests vont au-delà du "chemin idéal" standard du programmeur.
  • Communication et traçabilité plus claires : en appliquant une règle "Problème humain à sous-problème d'implémentation", les parties prenantes reçoivent des instructions claires sur les améliorations logiques apportées au lieu de lire des tickets remplis de détails techniques sur l'implémentation et sur la façon de les tester.

Pour illustrer l'impact de cette approche sur la vitesse de développement, P2ER a créé une nouvelle plate-forme en six mois, alors qu'il lui aurait fallu de nombreuses années avec ses méthodes établies. L'humain reste le dernier rempart de qualité, en examinant les demandes d'extraction qui ont déjà été validées par les agents.

Informations techniques pour les équipes

Lors de la création de ce workflow, P2ER a identifié plusieurs stratégies qui l'ont aidé à passer de l'expérimentation à un modèle de développement mature assisté par des agents.

Ces stratégies peuvent aider d'autres équipes à affiner leurs propres implémentations agentiques :

Optimiser l'utilisation des jetons grâce à l'injection de scripts et au traitement par lot de la CLI

Les serveurs MCP peuvent devenir gourmands en jetons lors de longues sessions de développement si les agents s'appuient uniquement sur la navigation pas à pas (par exemple, prendre un instantané, trouver un ID, remplir une entrée et attendre). Pour minimiser ces frais généraux, P2ER utilise une approche à deux volets :

  • Injection de script intégré : pour les interactions ciblées, comme l'authentification via des formulaires React complexes, les agents utilisent l'outil evaluate_script pour injecter du JavaScript vanilla directement dans le navigateur. Cela contourne les remplacements de setter intégrés et exécute plusieurs actions à la fois, ce qui permet d'économiser de nombreux tours de conversation.
  • Traitement par lot des scripts CLI : lorsque les agents rencontrent un problème ou un flux de navigation extrêmement long et répétitif, ils passent à un traitement par lot CLI. Au lieu de dépenser des jetons pour des outils MCP individuels et répétés ou d'écrire des scripts d'automatisation personnalisés à partir de zéro, P2ER invite la CLI Chrome DevTools à conserver et à regrouper les actions du navigateur. Cela permet aux agents d'exécuter de manière programmatique des flux entiers en plusieurs étapes en une seule fois, ce qui réduit considérablement la surcharge liée à la communication constante entre le modèle et l'outil.

Automatiser le suivi des performances avec l'analyse des traces

Au lieu de s'appuyer uniquement sur la perception humaine, P2ER a créé une compétence review-performance qui utilise les outils de développement pour que les agents puissent exécuter des audits Lighthouse automatisés et des traces de performances.

Les agents utilisent les outils performance_start_trace et performance_analyze_insight pour capturer et examiner les Core Web Vitals (LCP, INP, CLS), et identifier les goulots d'étranglement du thread principal ou les décalages de mise en page. Pour compléter la porte de qualité, les agents peuvent exécuter un lighthouse_audit complet afin de se prémunir spécifiquement contre les régressions en termes d'accessibilité (a11y), de SEO et de bonnes pratiques générales sur le Web. Ils s'assurent ainsi que seul un code de haute qualité est envoyé pour une demande d'extraction.

Améliorer la validation avec les Outils pour les développeurs Chrome pour les agents

En plus de leurs compétences personnalisées, P2ER utilise les fonctionnalités de base du serveur MCP des outils pour les développeurs Chrome pour effectuer la validation fonctionnelle. Cela inclut l'utilisation du serveur pour émuler différents appareils et tester la réactivité, en s'assurant que l'interface utilisateur fonctionne sur différentes tailles d'écran et différents appareils.

En utilisant le serveur MCP pour parcourir l'application, les agents peuvent identifier les différences visuelles entre les mises en page et l'implémentation réelle, ce qui permet de détecter les erreurs que les tests statiques ignorent souvent.

Ressources

Pour explorer plus en détail le cas d'utilisation de P2ER, découvrez toutes les compétences mentionnées dans le dépôt GitHub associé.

Pour vous lancer et découvrir comment implémenter des workflows similaires avec les outils de développement pour les agents, consultez les ressources suivantes :