Je vérifie les fonctionnalités sans lancer l’appli

Quand un agent termine une fonctionnalité, je veux voir ce qu’il a fait.

Pas seulement lire son résumé ou savoir que les tests passent. Je veux observer le résultat et vérifier qu’il correspond à ce que j’avais demandé.

Avant, ça impliquait de lancer l’application en local, trouver le bon compte, naviguer jusqu’à l’écran concerné et reproduire le parcours. Aujourd’hui, je demande à l’agent de me fournir une vidéo de démonstration.

La plupart du temps, je peux valider sans ouvrir l’application.

La vidéo arrive après les autres vérifications

La vidéo ne remplace pas les tests.

Pendant le développement, l’agent dispose déjà de plusieurs boucles de feedback : lint, tests unitaires, tests d’intégration et reviews de code par d’autres agents. La démonstration vient après.

Il connaît la fonctionnalité qu’il vient de développer. Son travail est alors de choisir un parcours qui me permette d’en examiner le comportement. Il n’y a pas un format identique pour toutes les vidéos : ce qu’il faut montrer dépend du changement.

Dans mon workflow actuel, il prépare les vidéos avant d’ouvrir la pull request. La démonstration fait donc partie du livrable, pas d’une vérification supplémentaire que je dois lui réclamer après coup.

Je regarde le résultat. S’il ne correspond pas à ma demande, je lui explique ce qui ne va pas. Il corrige, puis me fournit une nouvelle vidéo.

Les tests passent, mais le loading clignote

Un cas m’est arrivé plusieurs fois : un indicateur de chargement apparaissait pendant une durée très courte, peut-être 300 millisecondes, avant de laisser place aux données.

Le comportement était fonctionnel. Le loading s’affichait pendant le chargement, puis disparaissait lorsque les données étaient disponibles. Mais visuellement, ce passage éclair était désagréable.

La vidéo rendait le problème évident.

J’ai demandé à l’agent de retarder l’apparition du loading : si les données arrivent rapidement, inutile de faire surgir un indicateur pour le retirer aussitôt.

Je lui ai aussi demandé de prendre ce point en compte pour les développements suivants. Il a modifié son skill — la procédure qu’il consulte pour travailler — en conséquence. Depuis, je n’ai plus observé cette erreur.

C’est un intérêt important d’Hermes pour moi : mon retour ne reste pas seulement dans une conversation et ne sert pas uniquement à corriger la fonctionnalité du jour. Il peut devenir une consigne conservée pour la suite.

Il a aussi fallu améliorer les vidéos

Au début, les enregistrements réalisés avec Playwright n’étaient pas assez lisibles.

On voyait l’interface changer, mais pas le curseur de la souris ni l’endroit où l’agent cliquait. Une page apparaissait, puis une autre, sans que le geste soit visible.

J’ai donc fait améliorer le rendu.

Les vidéos montrent maintenant un curseur et un marqueur au moment du clic. Lorsqu’un scénario comporte du drag-and-drop, on peut suivre le déplacement. Lorsqu’il comporte du son, celui-ci est intégré à la vidéo.

Ces éléments font désormais partie de la procédure de création des démonstrations.

Ça peut sembler secondaire, mais pour vérifier un comportement, j’ai besoin de comprendre ce qui l’a déclenché. Voir l’effet sans voir l’action rend la démonstration plus difficile à suivre.

L’agent apprend aussi à se repérer dans l’application

Produire une vidéo demande parfois des informations que l’agent n’a pas encore : un compte particulier, une autorisation ou une façon précise d’accéder au scénario.

Quand il est bloqué, il me le dit et je lui fournis ce qui manque.

Au fil des fonctionnalités, il enrichit aussi un skill qui décrit le fonctionnement de l’application. Cette sorte de mapping l’aide à se repérer et à préparer les démonstrations suivantes avec moins d’intervention de ma part.

L’autonomie se construit donc progressivement. Elle dépend aussi de ce qu’on conserve après chaque difficulté rencontrée.

La vidéo reste un moyen, pas une obligation

Il m’arrive encore d’ouvrir l’application.

J’ai notamment dû vérifier le contenu d’une longue modale. En vidéo, je ne contrôlais pas le scroll : il fallait mettre sur pause au bon moment pour examiner chaque partie. La lancer moi-même était simplement plus pratique.

Il y a aussi un coût en délai. Certaines vidéos prennent du temps à produire, ce qui retarde l’ouverture de la PR. Pour l’instant, je n’ai pas rencontré d’urgence qui m’ait obligé à les supprimer du workflow. Mais je peux imaginer demander un jour une livraison sans vidéo parce que le temps manque.

Mon objectif n’est pas de m’interdire d’ouvrir l’application. C’est de ne plus avoir à la lancer par défaut pour chaque vérification.

Les tests et les reviews me donnent des retours sur le code et son comportement attendu. La vidéo me permet d’examiner le résultat obtenu, notamment les détails visuels et les transitions.

Je reste celui qui décide si ce résultat me convient. Mais je n’ai généralement plus besoin de refaire moi-même tout le parcours pour prendre cette décision.