Date de publication : 10 novembre 2026
Policybazaar est l'une des principales plates-formes d'assurance en Inde, avec plus de 97 millions de clients enregistrés. Environ 80 % de ses clients visitent le site Web chaque mois. Sa société mère, PB Fintech, a récemment lancé Pensionbazaar, une plate-forme de planification de la retraite de bout en bout, qui est une marque de Paisabazaar Marketing & Consulting Private Limited.
Les deux équipes utilisent déjà des agents de codage, qui écrivent du code rapidement, mais ne peuvent pas voir ce que ce code fait dans un navigateur. Les agents utilisaient souvent des modèles Web obsolètes et n'avaient aucun moyen de vérifier si un écran s'affichait correctement. Les ingénieurs devaient donc toujours tout vérifier manuellement.
Pour résoudre ce problème, les deux entreprises ont combiné deux outils dans leur workflow agentique : Modern Web Guidance pour enseigner aux modèles les normes Web modernes, et les Outils de développement Chrome pour les agents pour fournir à ces agents un navigateur sans interface graphique en direct afin d'inspecter et de vérifier leur travail.
Voici l'impact :
92 %
Moins d'efforts d'audit manuel sur environ 30 pages de destination Policybazaar
> 90 %
Développement et tests plus rapides pour les nouvelles pages de Pensionbazaar, passant d'environ quatre jours à quelques heures
> 90 %
Moins de bugs d'UI signalés sur les nouveaux écrans Pensionbazaar
Le défi : un code rapide, une validation lente
Policybazaar et Pensionbazaar ont rencontré deux goulots d'étranglement différents que les workflows de codage IA standards ne pouvaient pas optimiser au niveau de la production.
Pensionbazaar : nouveaux écrans avec de longs cycles d'assurance qualité
Pensionbazaar avait besoin de dizaines de nouveaux écrans complexes, tels que le calculateur de score de liberté de retraite en plusieurs étapes, des projections de dépenses d'investissement personnalisables et des rapports de recommandations automatisés. L'équipe les a créés avec des agents de codage et le serveur MCP Figma, mais deux problèmes ont continué à allonger les cycles d'assurance qualité.
Tout d'abord, les agents codaient à l'aveugle. Un modèle de base peut générer du code, mais il ne peut pas voir l'interface affichée, comparer les styles calculés avec les spécifications de conception, détecter les décalages de mise en page ni lire une cascade réseau. Les problèmes associés, tels que les éléments d'UI tronqués et les décalages de mise en page, ont donc été détectés lors de l'assurance qualité manuelle.
Deuxièmement, le code généré était bloqué dans le passé. Sans connaissance de la plate-forme Web moderne, les agents ont eu recours à des solutions de contournement obsolètes, en écrivant des modaux JavaScript lourds au lieu d'utiliser l'élément <dialog> intégré, en ajoutant des polyfills inutiles et en omettant des indications de performances telles que fetchpriority.
Policybazaar : 30 pages de destination et un audit manuel
L'équipe chargée de l'assurance-vie chez Policybazaar gère environ 30 pages de destination pour différents produits d'assurance, et chaque page peut présenter des variantes pour différentes campagnes marketing. Ensemble, ils reçoivent 200 000 à 300 000 visiteurs par jour, et chaque page bénéficie de mises à jour mensuelles de la conception et de la logique métier. L'équipe doit maintenir des scores Core Web Vitals élevés et s'assurer que chaque variante reste accessible et s'affiche correctement sur toutes les tailles d'écran.
Avant l'automatisation, un ingénieur auditait chaque page manuellement :
- Exécutez PageSpeed Insights pour collecter des données utilisateur réelles.
- Évaluez les scores et les recommandations Core Web Vitals.
- Inspectez la compilation de développement ou de préproduction, diagnostiquez les problèmes à l'origine des scores et appliquez des correctifs de code.
Le processus était lent, répétitif et ne s'adaptait pas à l'échelle. Cela laissait la place à des optimisations manquées, à une couverture d'audit incohérente, à des régressions de performances non détectées et à des retards de publication.
Avant de modifier leur workflow, les équipes se sont fixé trois objectifs : réduire de plus de 80 % le temps consacré par les développeurs aux audits de performances tout en assurant une couverture continue des audits, raccourcir les délais d'assurance qualité grâce à des rapports vérifiés et réduire les bugs d'interface utilisateur signalés parce qu'un écran ne correspondait pas à ses wireframes.
La solution : une boucle de code à vérifier
Pensionbazaar a comblé l'écart entre l'écriture du code et sa vérification. L'agent écrit le code, démarre une instance de navigateur propre, audite la page de manière programmatique pour vérifier la parité visuelle, les ruptures de mise en page, les erreurs de console et les performances, et corrige les problèmes qu'il trouve avec une intervention humaine minimale. Son agent récupère la conception à partir de Figma MCP, ce qui lui permet de comparer la page affichée avec ce que les concepteurs avaient prévu.
La vidéo suivante montre cette boucle en action. L'agent lit les conceptions Figma d'un nouvel écran, les implémente, puis utilise les Outils de développement Chrome pour les agents afin d'inspecter la page affichée et de corriger les différences qu'il trouve.
Étape 1 : Ancrez l'agent dans les standards Web modernes
L'équipe de Pensionbazaar souhaitait que le code généré respecte les bonnes pratiques du Web moderne, utilise les fonctionnalités actuelles de la plate-forme et fonctionne toujours dans les anciens navigateurs. Il est fastidieux de vérifier cela manuellement, et les agents ne sont pas toujours à jour avec la plate-forme. Modern Web Guidance résout ce problème. Il s'agit d'une compétence d'agent, écrite et gérée par des experts Web de Chrome et de la communauté Web, qui couvre plus de 200 cas d'utilisation. Il oriente les agents vers les API de plates-formes Web modernes, ainsi que vers les bonnes pratiques en matière de performances et d'accessibilité qui correspondent à votre cible Baseline. Si vous ne définissez pas de cible, la valeur par défaut est Baseline Widely Available.
Une fois que l'agent a extrait le contexte des fichiers Figma, il utilise Modern Web Guidance pour écrire le code. Pour Pensionbazaar, cela a modifié le code de trois manières :
- Les éléments natifs ont remplacé les solutions de contournement JavaScript. L'agent a utilisé l'élément
<dialog>intégré et l'API Popover pour les fenêtres modales de détails du forfait, ainsi que CSS Grid et Flexbox pour les fiches de résumé financier. - L'agent a ajouté des conseils d'optimisation que les modèles de base omettent généralement.
Il s'agissait notamment de
fetchpriority="high"sur les images LCP principales, deloading="lazy"sur les fiches de plan situées sous la ligne de flottaison et d'un budget d'exécution basé sur le temps avecscheduler.yield()pour protéger l'Interaction to Next Paint (INP). - Les fonctionnalités modernes n'ont pas endommagé les anciens navigateurs. Pensionbazaar est compatible avec les anciennes versions de navigateur, qu'il définit dans Browserslist. L'agent a utilisé des fonctionnalités telles que la pseudo-classe CSS
:user-invalidetautoComplete="one-time-code"dans le champ du mot de passe à usage unique (OTP). Les anciens navigateurs les ignorent, et les fonctionnalités de base continuent de fonctionner.
Les modèles de base n'étaient pas loin du compte. En termes de performances, l'équipe a constaté qu'ils étaient conformes à environ 70 % aux bonnes pratiques. Le rapport de l'agent a listé 12 règles Modern Web Guidance qui ont permis de combler l'écart restant. Quatre exemples :
| Région | L'écart du modèle de base | La règle Modern Web Guidance |
|---|---|---|
| Chargement de l'image | Combinaisons contradictoires hallucinée, comme l'association de fetchpriority="high" avec loading="lazy". |
Interdit explicitement de les combiner et limite le nombre d'images à priorité élevée à une ou deux par page. |
| Stabilité de la mise en page | content-visibility: auto suggéré pour les performances, mais contain-intrinsic-size omis. |
Nécessite d'associer les deux propriétés pour éviter des décalages de mise en page importants lors de l'affichage du contenu. |
| Cession du thread principal | Utilisation de scheduler.yield() de manière générique sans modèle de date limite. |
Applique un délai strict (performance.now() + 50) pour protéger l'Interaction to Next Paint (INP). |
| Mise en cache du service worker | Vous n'avez pas pris en compte les envois de formulaires hors connexion. | Avertit l'agent que les service workers ne peuvent pas mettre en cache de manière native les requêtes autres que GET. |
Pour Pensionbazaar, notre priorité était de créer un code de qualité dès le premier jour afin d'éviter toute dette technique par la suite. Modern Web Guidance a guidé notre agent de codage pour qu'il adopte les normes Web modernes et les bonnes pratiques de performances, tout en respectant nos objectifs spécifiques de compatibilité avec les navigateurs. Cela a considérablement facilité et accéléré nos examens de code d'interface, ce qui a permis d'améliorer notre délai de développement.
Aman Soni, Engineering Manager, Policybazaar
Étape 2 : Donnez un navigateur à l'agent
Les outils de développement Chrome pour les agents sont un ensemble d'outils, y compris un serveur MCP, une CLI et des compétences d'agent, qui permettent aux agents de codage d'accéder en temps réel aux données de débogage d'exécution, telles que les journaux de la console, le trafic réseau, l'arborescence d'accessibilité et d'autres fonctionnalités des outils de développement.
L'équipe a installé les Outils de développement Chrome pour les agents en tant que plug-in dans son agent de codage, Claude Code :
# Add the marketplace registry
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
# Install the plugin (MCP server and skills)
/plugin install chrome-devtools-mcp@chrome-devtools-plugins
L'équipe souhaitait que chaque test s'exécute dans une instance de navigateur propre, afin que les extensions Chrome installées n'affectent pas les résultats et que les données personnelles ou sensibles ne puissent pas fuiter. Pour ce faire, ajoutez --isolated au tableau args dans la configuration du serveur MCP :
{
"args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}
Si vos tests nécessitent une session de navigateur connectée existante, utilisez plutôt --autoConnect.
Étape 3 : Laissez l'agent vérifier et corriger son propre travail
L'équipe d'ingénierie liste les vérifications dans les instructions de l'agent, soit sous forme de requête, soit sous forme de compétence de l'agent. De manière générale, l'agent effectue les opérations suivantes :
- Inspecte l'arborescence DOM et le CSS calculé, et les compare à la conception Figma.
- Redimensionne la page pour l'adapter aux fenêtres d'affichage mobiles afin de tester la responsivité.
- Enregistre les traces de performances pour identifier les frames d'animation longs (LoAF) causés par des scripts, des ressources bloquant l'affichage et d'autres problèmes de performances.
- Réécrit le code pour corriger les incohérences de conception, les problèmes de performances et les exceptions de la console avant qu'un ingénieur ne l'examine.
Le tableau suivant indique les outils de développement Chrome pour les agents qui sont compatibles avec chaque vérification :
| Vérifier | Outils |
|---|---|
| Tester la réactivité sur différentes fenêtres d'affichage | resize_page redimensionne la fenêtre de la page selon des dimensions explicites. emulate émule des environnements d'appareils spécifiques. take_screenshot capture le résultat. |
| Comparer le DOM et le CSS calculé avec la conception Figma | take_snapshot renvoie un instantané textuel de la page en fonction de l'arborescence d'accessibilité. get_css_styles lit les règles CSS appliquées. evaluate_script exécute une fonction JavaScript sur la page. |
| Identifier les problèmes liés aux LoAF, aux ressources bloquant l'affichage et aux Core Web Vitals | click et drag émulent les interactions. performance_start_trace et performance_stop_trace enregistrent une trace des performances. performance_analyze_insight renvoie des diagnostics détaillés pour les insights de la trace. list_network_requests et get_network_request affichent l'activité réseau. lighthouse_audit audite les aspects non liés aux performances, tels que le SEO et l'accessibilité. |
Lorsque l'agent détecte un problème, tel qu'un texte tronqué sur les petits écrans, un flex wrap défectueux ou une image non optimisée qui entraîne un décalage de mise en page, il exécute une courte boucle de correction :
- Les Outils de développement Chrome pour les agents capturent l'erreur exacte.
- L'agent analyse les données et réécrit le code CSS ou JavaScript problématique.
- L'agent actualise la page pour confirmer la correction.
Sur un écran, l'agent a affiché la page et a constaté que la mise en page, l'espacement et le dégradé de l'en-tête ne correspondaient pas à la conception. Il a corrigé les fichiers .scss concernés. Il a également interagi avec la page, par exemple en développant les accordéons pour vérifier que leur état ouvert correspondait aux conceptions.
Étape 4 : Transmettez un rapport validé au contrôle qualité
Une fois la validation terminée, l'agent fournit un code prêt pour la production ainsi qu'un rapport d'audit pour l'équipe d'assurance qualité. Le rapport comprend les informations suivantes :
- Une comparaison visuelle avec la conception Figma qui met en évidence les différences de pixels, créée à partir de captures d'écran, d'instantanés DOM et de styles calculés.
- Captures d'écran de la page affichée sur différentes tailles d'écran.
- Diagnostics des Core Web Vitals et des performances de
performance_start_traceetperformance_analyze_insight, tels que le Speed Index et le Total Blocking Time (TBT). - Scores Lighthouse pour le SEO, les bonnes pratiques et l'accessibilité de
lighthouse_audit. - Vérifications de réussite ou d'échec pour les interactions, telles que la réduction des lignes et les boutons d'activation/désactivation, ainsi que les erreurs de la console et les changements d'état de l'application, tels que la modification des lignes, la suppression des lignes et les états vides.
Appliquez la même approche à 30 pages de campagne
Sur sa plate-forme principale, Policybazaar a remplacé les exécutions manuelles de PageSpeed Insights par des audits exécutés via les Outils de développement Chrome pour les agents dans Kiro. Avant la mise en ligne d'une page de campagne, un ingénieur déclenche un audit de l'URL de préproduction pour mobile et ordinateur. L'agent exécute des audits de performances et Lighthouse, et les Outils de développement Chrome pour les agents extraient automatiquement les données réelles du rapport sur l'expérience utilisateur de Chrome (CrUX) en plus des données de laboratoire. Cela a complètement remplacé l'étape PageSpeed Insights.
L'agent indique ensuite les scores de performances, les goulots d'étranglement qu'il a détectés et une liste prioritaire d'améliorations à apporter par un ingénieur. Lors d'un audit de version préliminaire, il a signalé des appels d'API non critiques qui se déclenchaient les uns après les autres lors du chargement de page et entraient en concurrence avec le travail de rendu critique. L'équipe a résolu le problème avant la mise en ligne de la page.
L'agent effectue désormais 12 audits de performances dans le temps qu'il faut à un ingénieur pour en terminer un. Cela représente une réduction de 92 % du travail manuel.
Les performances Web sont importantes pour nous afin de maintenir une bonne expérience utilisateur, mais l'audit manuel, l'évaluation des cascades et des traces sur des dizaines de pages de destination étaient fastidieux et constituaient un goulot d'étranglement majeur. Les outils de développement Chrome pour les agents ont transformé ce processus et réduit de 92 % le temps d'audit des performances de nos ingénieurs, ce qui leur permet de se concentrer sur des tâches plus complexes.
Aman Soni, Engineering Manager, Policybazaar
Impact
Modern Web Guidance et les outils de développement Chrome pour les agents ont transformé les tests d'interface chez Policybazaar et Pensionbazaar, qui sont passés d'un processus manuel et réactif à un processus automatisé et proactif. Le tableau suivant compare les workflows avant et après la modification :
| Région | Avant : examen manuel et modèles de base | Après : Modern Web Guidance et les Outils de développement Chrome pour les agents |
|---|---|---|
| Effort d'audit des performances (Policybazaar) | Un ingénieur a exécuté PageSpeed Insights, examiné les Core Web Vitals et appliqué manuellement des correctifs pour chacune des quelque 30 pages de destination. | 92 % d'efforts manuels en moins. L'agent effectue 12 audits pendant le temps qu'il fallait à un ingénieur pour en faire un. |
| Couverture d'audit (Policybazaar) | La couverture de l'audit n'était pas cohérente entre les variantes de la campagne. | Couverture de test des performances de 100 % pour les pages de campagne. |
| Nouveau délai de traitement des écrans (Pensionbazaar) | Quelques jours entre le code et l'écran validé. | Quelques heures, soit plus de 90 % plus rapidement. |
| Design parity bugs (Pensionbazaar) | L'UI tronquée et les décalages de mise en page ont atteint l'assurance qualité manuelle. | Le nombre de bugs d'UI signalés a diminué de plus de 90 %. |
Cette réduction de 92 % a dépassé l'objectif de l'équipe, qui était de plus de 80 %. Les régressions de la page de destination sont détectées avant d'atteindre l'environnement de préproduction ou d'assurance qualité. Sur Pensionbazaar, le code arrive déjà audité avec des captures d'écran pour plusieurs fenêtres d'affichage, ce qui réduit les allers-retours entre la conception, l'ingénierie et l'assurance qualité.
Points à retenir pour votre équipe
- Ancrez votre agent dans des conseils officiels. Les conseils personnalisés, comme Modern Web Guidance, permettent aux agents d'éviter les modèles obsolètes et de maintenir votre code dans vos objectifs de référence.
- Ne laissez pas un agent marquer une tâche d'interface comme terminée tant qu'il n'a pas vérifié la page affichée. Les outils de développement Chrome pour les agents permettent à l'agent d'inspecter la mise en page, les fenêtres d'affichage et les traces de performances dans un navigateur réel.
- Définissez des critères de sortie clairs pour la boucle. Définissez des limites d'étapes et des conditions de réussite et d'échec explicites pour que l'agent ne tourne pas en boucle et ne gaspille pas de jetons.
- Commencez par les pages à forte fréquence basées sur des modèles. Les workflows en boucle fermée sont particulièrement utiles lorsque la rapidité d'exécution est essentielle.
- Exécutez les audits dans un navigateur propre. Utilisez
--isolatedpour que les extensions et les données mises en cache n'affectent pas les résultats et n'exposent pas de données à caractère personnel.