Comment un agent IA nous aide à tester les réactions de Maestro

Un utilisateur peut répondre trop vite, demander une correction ou revenir sur sa décision. Notre banc de test simule ces situations pour chercher les blocages, avec des limites bien définies.

Que se passe-t-il si vous demandez une modification après avoir validé un document ? Ou si votre réponse ne correspond pas à la question posée ? Nous utilisons un banc de test pour éprouver le moteur de Maestro sur des projets jetables, avant de retrouver ces situations dans l’application.

Deux types de tests, deux rôles

Les tests automatiques à blanc utilisent des réponses préparées et des erreurs injectées volontairement. Ils sont rejoués lors des contrôles du code, sans appel à un modèle IA payant. Leur intérêt est de vérifier qu’un même incident produit toujours la réaction attendue.

Les essais avec de vrais modèles sont lancés séparément. Un modèle joue les agents de Maestro ; un autre joue la personne qui décrit son besoin et répond aux propositions. Ces essais consomment de l’IA, avec un plafond configuré par scénario, fixé à 15 dollars par défaut dans ce banc.

Cinq façons de répondre

Le premier comportement est conciliant : il valide si le document convient. Le deuxième est pressé : ses réponses sont courtes et il veut avancer. Le troisième est exigeant : il réclame une précision ou une correction avant d’accepter.

Le quatrième change d’avis, répond parfois à côté ou revient sur un choix validé. Le cinquième cherche les limites : il formule des demandes contradictoires ou essaie de faire sauter une étape. Ce sont des consignes données à un modèle, pas cinq personnes observées ni un panel représentatif.

Un exemple de contrôle utile

Un scénario de notre banc fait échouer volontairement une commande de vérification, alors que l’agent simulé affirme que tout est conforme. Le contrôle doit empêcher la tâche de passer à « terminée » sur cette seule affirmation et faire apparaître la cause de l’échec.

Ce test cible une règle précise : une validation doit s’appuyer sur un résultat vérifié. Il ne vérifie pas toutes les fonctions de l’application. Nous pouvons ensuite rejouer la même situation après une correction pour repérer un retour du défaut.

Ce que le rapport permet de retrouver

Chaque essai conserve son scénario, les réponses jouées et les contrôles réussis ou échoués. Les essais avec modèles réels ajoutent leur consommation. Le rapport sert à reprendre un accroc précis et à décider d’une correction ; les rapports bruts restent internes.

Le banc exécute le moteur sans ouvrir la fenêtre de l’application. Il ne montre donc pas si un bouton est compréhensible, si une notification est visible ou si une personne trouve son chemin. Ces points demandent des essais dans l’interface.

Ce que ces essais ne prouvent pas

Un scénario réussi ne garantit ni la sécurité du produit ni l’absence d’autres bugs. Un utilisateur simulé peut manquer une difficulté qu’une personne rencontre immédiatement. Les contrôles techniques, la relecture et les retours d’utilisateurs apportent des observations différentes.

Pour votre propre application, choisissez un parcours réel, puis rejouez-le après une modification. Les cas qui échouent doivent rester dans la liste des essais. C’est aussi la raison pour laquelle nous racontons les limites de nos évaluations.