Product Loop, Partie 2 : Trouver les bugs que personne n'a signalés

Dans la Partie 1 de cette série, nous avons exploré pourquoi une réponse réussie de l'agent ne signifie pas toujours un résultat réussi pour le client — et pourquoi la boucle produit agentique, de l'intention à l'exécution, la correction et le résultat, est la bonne unité de mesure.

Product Loop est un système de diagnostic construit par l'équipe d'ingénierie de GoDaddy Airo AI Builder. Il connecte les conversations clients, les transcriptions du support, la télémétrie et l'historique du code pour trouver des problèmes qui ne se manifestent jamais comme des erreurs explicites — puis génère des tickets Jira structurés pour que les développeurs puissent agir. Il est déjà en production et nous aide à améliorer GoDaddy Airo AI Builder. Cet article se concentre sur la couche de diagnostic : trouver les problèmes clients, comprendre leurs causes et aider les développeurs à les corriger.

Un modèle mental simple : des boucles dans des boucles

Pensez au fonctionnement d'un restaurant.

Un cuisinier goûte un plat et ajuste l'assaisonnement. La cuisine vérifie que toute la commande est correcte avant de l'envoyer. Le manager observe de nombreuses commandes et remarque que les clients demandent régulièrement à réchauffer leur nourriture. Chaque commande a été préparée correctement, mais quelque chose se passe peut-être mal entre la cuisine et la table.

Ce sont trois niveaux de feedback différents :

• Boucle d'exécution — Prendre une action, vérifier le résultat et décider quoi faire ensuite. Pour un agent, cela peut signifier appeler un outil et lire sa réponse.
• Boucle de tâche — Continuer à travailler jusqu'à ce que la tâche complète réponde à ses exigences — par exemple, construire une page et vérifier qu'elle fonctionne.
• Boucle produit — Observer les expériences clients, enquêter sur les problèmes récurrents et utiliser les résultats pour améliorer le produit.

Le manager doit encore enquêter sur pourquoi les repas arrivent froids. Le schéma lui dit où chercher, pas automatiquement ce qui l'a causé. Product Loop joue un rôle similaire.

Quand rien n'échoue, mais le client peine encore

Imaginez un client qui demande à Airo de déplacer une image en haut d'une page. L'agent dit que c'est fait. Le client répond : « Non, je voulais dire au-dessus du titre. » Une autre tentative suit, puis une autre correction.

Les appels d'outils pourraient tous réussir. Le client pourrait finalement obtenir le bon résultat. Pourtant, un changement simple a nécessité plus d'effort qu'il ne le devrait.

Un compteur d'échecs peut manquer cette expérience. Observer des conversations similaires peut révéler s'il s'agit d'un malentendu isolé ou d'un problème récurrent dans la façon dont l'agent interprète le placement des images. Toute correction n'indique pas un bug ; une certaine itération est normale. La question utile est de savoir si les clients doivent régulièrement contourner le même comportement.

Parfois, satisfaire les clients signifie supprimer l'explication supplémentaire qu'ils n'auraient jamais dû avoir à donner.

Comment nous rassemblons les preuves

Product Loop combine des sources qui révèlent chacune une partie différente du problème :

L'agent Product Loop fonctionne sur le harnais d'agent Claude. Nos conversations clients sont capturées dans différents systèmes backend, où l'agent peut interroger. La connaissance du produit et de ses capacités est obtenue via le code source lui-même, ce qui aide Product Loop à interpréter ces signaux d'un point de vue code.

La partie importante n'est pas simplement de mettre plus de texte devant un modèle. C'est de connecter les preuves autour du même objectif client, de la même application, de la même capacité et de la même période. Les identifiants de session et d'application fournissent des liens directs quand ils sont disponibles ; une formulation similaire seule ne suffit pas à établir que deux enregistrements décrivent le même incident.

D'un symptôme répété à une cause probable

Voici comment une investigation pourrait se dérouler, en utilisant l'exemple du placement d'image. C'est une illustration, pas un incident de production spécifique.

La première question est de savoir si le problème se répète chez plusieurs clients. Des demandes et corrections similaires peuvent révéler un schéma, mais le décompte doit refléter les clients et applications affectés — pas seulement de nombreux messages d'une longue conversation. Comparer ces conversations avec les appels d'outils et les logs aide ensuite à distinguer une action qui a échoué d'une qui a réussi avec la mauvaise interprétation.

Cette preuve donne à l'investigation du code une direction. Un changement récent dans la façon dont l'agent sélectionne les sections de page, par exemple, vaudrait la peine d'être examiné. Vérifier les issues Jira existantes pourrait aussi révéler que le comportement est antérieur à ce changement : il peut s'agir d'un ancien problème dont l'impact client avait été sous-estimé plutôt que d'une nouvelle régression.

Le timing seul ne prouve pas qu'un PR a causé un bug. Un changement fusionné peut même ne pas avoir atteint la production quand le problème s'est produit. Un diagnostic utile connecte le comportement, le chemin de code et la version déployée quand cette preuve est disponible — et rend l'incertitude claire quand elle ne l'est pas.

Un ticket Jira qui donne aux développeurs un point de départ

Quand Product Loop identifie un problème récurrent, il nous aide à générer un ticket Jira avec l'investigation attachée. Le ticket explique ce que les clients ont essayé de faire, ce qui s'est passé à la place et combien de clients ou d'applications ont été affectés dans la fenêtre de temps observée.

L'analyse de cause racine expose l'explication probable, ses preuves à l'appui et les questions encore ouvertes. Les références aux conversations, logs et code pertinents permettent à un développeur de vérifier le raisonnement. Quand un PR récent semble responsable, le ticket y pointe et explique la connexion plutôt que de simplement nommer un suspect.

Product Loop nous aide à classer les problèmes par portée et gravité. Le produit et l'ingénierie peuvent ensuite peser ces résultats par rapport à l'urgence, l'effort et d'autres engagements. Il soutient la priorisation plutôt que de transformer chaque schéma détecté en une décision automatique de feuille de route.

Du diagnostic à un correctif proposé

Traditionnellement, un bug pourrait attendre un rapport client, une escalade du support, une investigation et plusieurs transferts avant qu'un développeur ait suffisamment de contexte pour commencer. Product Loop rassemble une grande partie de cette collecte de preuves et de la préparation des tickets. Les développeurs passent moins de temps à reconstituer ce qui s'est passé et peuvent commencer avec une explication ciblée à vérifier.

Le même ticket donne aussi à notre agent de codage un point de départ utile. Avec un accès autorisé au code source, les agents de codage peuvent suivre les preuves citées, tester l'explication proposée et soumettre un PR avec un correctif et des tests de support.

Pourquoi garder un humain dans la boucle pour les fusions si le diagnostic est déjà si bon ?

Parce qu'un diagnostic plausible et un patch fonctionnel ne sont pas la même chose qu'un changement sûr. Un correctif pourrait traiter le symptôme plutôt que la cause, affecter un autre flux de travail ou négliger une contrainte de sécurité ou d'architecture. Bien que nous ayons automatisé la majorité de notre processus de révision de code, chaque changement passe encore par un réviseur humain qui vérifie le raisonnement, les tests et les conséquences plus larges du changement.

Ce qui change pour l'équipe — et le client

Pour l'équipe Airo chez GoDaddy, Product Loop change la façon dont nous décidons de ce qui nécessite de l'attention. Au lieu de commencer par un rapport client isolé et de reconstituer l'histoire, nos développeurs peuvent commencer avec les conversations, les logs et le code pertinent au même endroit. Notre équipe produit obtient une vue plus claire des problèmes qui continuent de se répéter — y compris les anciens problèmes du backlog dont l'impact client était facile à sous-estimer.

Pour les propriétaires de petites entreprises qui utilisent Airo, l'objectif n'est pas d'avoir une meilleure conversation avec un agent. C'est d'avoir leur site web prêt et de retourner à la gestion de leur entreprise. Devoir expliquer un placement d'image trois fois entrave cet objectif, même si chaque appel d'outil réussit. C'est pourquoi ce travail nous importe chez GoDaddy. Nous voulons qu'Airo enlève du travail des mains de nos clients, pas qu'il leur donne un autre système à dépanner.

Questions fréquentes

Product Loop est un système de diagnostic développé par l'équipe d'ingénierie de GoDaddy Airo AI Builder. Il connecte les données de conversations clients, les transcriptions du support, les logs de télémétrie, les pull requests GitHub et les issues Jira pour identifier les problèmes récurrents dans les produits IA agentiques — y compris les problèmes qui ne déclenchent jamais d'erreur explicite.

La boucle d'exécution couvre un seul cycle action-vérification (par exemple, appeler un outil et lire sa réponse). La boucle de tâche couvre la séquence complète d'étapes nécessaires pour accomplir un objectif client. La boucle produit opère au niveau le plus élevé — elle observe de nombreuses sessions clients pour trouver des schémas, des échecs récurrents et des lacunes systémiques qu'aucune session individuelle ne révèle seule.

Il corrèle les signaux de plusieurs sources : les corrections dans les conversations (où un client a dû ré-expliquer ou réessayer), les transcriptions du support, les logs d'appels d'outils et les changements de code récents. Un schéma de corrections similaires chez plusieurs clients — même quand chaque appel d'outil réussit — peut indiquer une mauvaise interprétation systématique qui n'apparaîtrait jamais dans un log d'erreurs.

Un diagnostic plausible et un patch fonctionnel ne sont pas la même chose qu'un changement sûr. Un correctif pourrait traiter le symptôme plutôt que la cause racine, introduire une régression dans un autre flux de travail ou manquer une contrainte de sécurité ou d'architecture. Les réviseurs humains vérifient le raisonnement, les tests et les conséquences plus larges avant que tout changement soit fusionné.

L'agent Product Loop fonctionne sur le harnais d'agent Claude, développé par Anthropic. Il interroge les systèmes backend internes de GoDaddy pour les données de conversations clients et utilise le code source du produit comme source de connaissance pour interpréter les signaux en contexte.

Dans le prochain article, nous verrons comment les mêmes signaux de production nous aident à construire des évaluations autour de ce que les clients font réellement.

C'est la Partie 2 d'une série sur la construction et la mesure de produits IA agentiques. Lisez la Partie 1 : Quand votre produit n'a plus un seul chemin pour commencer depuis le début.