5 preuves de progression quand on travaille avec des agents IA

Le test est vert. Il devait vérifier qu’un formulaire d’inscription refuse une adresse e-mail invalide. Le service a pourtant envoyé l’adresse à la base de données. La base a dépassé le délai d’attente et le test a considéré cette erreur comme le rejet attendu.

C’est un exemple construit pour la formation. En revue d’équipe, je partirais de ce résultat pour choisir la prochaine responsabilité à confier. Avant d’élargir le périmètre, je regarderais comment la personne a décelé le faux positif et vérifié la correction.

En bref

Ce qu’on examine	Ce qu’on cherche
Le résultat	Le contrôle distingue l’erreur attendue d’une panne et le cas valide passe
La progression	La personne cadre, vérifie, explique, corrige et transmet sur un périmètre connu
La prochaine responsabilité	Une tâche différente à essayer, avec l’aide et la revue convenues

Faire rougir le bon test

L’assertion assert.rejects(() => register('adresse-invalide')) accepte n’importe quel rejet. Une panne de la base suffit donc à la faire passer. Dans l’exercice, l’agent repère cette faiblesse, puis propose un correctif qui renvoie la même erreur pour toutes les adresses. Le cas invalide passe avec une assertion plus précise. Le cas valide échoue.

On peut vérifier le contrat avec un dépôt simulé qui enregistre les appels à save. Ici, makeRegister construit le service avec ce dépôt.

const saved = []
const register = makeRegister({
  async save(email) { saved.push(email) },
})

await assert.rejects(() => register('adresse-invalide'), {
  code: 'EMAIL_INVALIDE',
})
assert.deepEqual(saved, [])

await register('valide@example.test')
assert.deepEqual(saved, ['valide@example.test'])

Je rejouerais le contrôle sur la version sans validation. Avec le dépôt simulé, elle accepte l’adresse invalide et le test échoue. Avec une base qui simule un délai dépassé, l’erreur de la base ne correspond pas à EMAIL_INVALIDE. La variante qui refuse toutes les adresses échoue sur le cas valide. Ces 2 contre-exemples aident à relire le diff qui corrige le service. Un diagnostic juste et un correctif à vérifier, dans Du code au merge

Avant, l’adresse invalide atteint la base et un délai dépassé fait passer le test à tort. Après, le test exige EMAIL_INVALIDE sans écriture et vérifie que l’adresse valide est enregistrée. — Le contrôle distingue l’erreur attendue d’une panne et le cas valide passe

Observer 5 preuves sur le même changement

1. Cadrer

Avant de lancer l’agent, le développeur fixe la règle. Une adresse invalide doit être rejetée avant toute écriture. Une adresse valide doit encore être enregistrée. Il limite le changement au service et à ses tests. Si le contrat sur les erreurs reste ambigu, il revient vers la personne qui en a la responsabilité. Le ticket ou la consigne versionnée permet de retrouver cette décision pendant la review.

2. Vérifier

Le développeur fait échouer le test sur la version fautive, puis rejoue le contrôle sur le diff corrigé. Il conserve la commande et la révision testée. On peut alors savoir quel comportement a été vérifié et sur quel code. Le dépôt simulé couvre l’appel à save dans cet exercice. Il reste à tester le comportement de la vraie base si le changement touche aussi la persistance.

3. Expliquer

Je demanderais une prédiction avant de modifier le cas. Si la base devient indisponible avec une adresse valide, que devrait-il se passer ? La validation de l’adresse doit réussir, puis l’écriture peut échouer. La réponse permet de vérifier que la personne sait situer les deux décisions dans le code. Le protocole UVAL développe ce travail de compréhension et de transfert.

4. Corriger

Le diff de l’agent donne une piste. La personne reproduit le rejet du cas valide, isole la condition trop large et rétablit la validation à l’endroit prévu. Elle relance les 2 cas sur la correction. Si l’équipe retrouve régulièrement le même défaut dans ses reviews, elle peut en faire un contrôle partagé. Transformer les commentaires récurrents en contrôles testés

5. Transmettre

Un collègue repart de la révision indiquée avec la commande, les données simulées et les résultats attendus. On observe où il bloque. S’il doit demander quelle erreur injecter ou dans quel ordre lancer les tests, ce détail manque à la passation. L’essai suivant peut se faire sur un autre champ du formulaire, avec une règle et des effets à vérifier différents.

Choisir la prochaine responsabilité

Ces périmètres servent à choisir une mise en situation dans la grille de progression que l’équipe utilise déjà. Une personne peut concevoir les tests d’un service qu’elle connaît et demander une revue rapprochée sur un flux nouveau. Noter l’aide reçue rend cette différence visible, qu’elle vienne de l’agent ou d’un collègue.

Remplir la grille en review

Prenez un changement réel et une ligne par capacité que vous avez pu observer. Voici une ligne remplie pour le scénario d’inscription.

Capacité	Comportement observé	Trace examinable	Périmètre et aide reçue	Limite	Prochain essai
Vérifier	Fait échouer le contrôle sur la version fautive et vérifie le cas valide après correction	Révision du diff, commande et sorties des 2 exécutions	Inscription avec dépôt simulé. L’agent a signalé l’assertion vague. Le lead a aidé à distinguer les erreurs	La persistance réelle demande un test d’intégration	Choisir le contrôle d’un autre formulaire, puis le faire rejouer à un collègue

En fin de review, retenez une responsabilité à essayer sur le prochain changement et convenez du niveau d’aide. C’est aussi le point de départ du parcours avancé de formation, où l’exercice se rejoue sur une tâche de l’équipe.

À retenir

(Ce que vous savez maintenant)

Un test de rejet générique peut passer sur une erreur de base de données
Le cas invalide et le cas valide permettent d’écarter une correction qui refuse tout
Les 5 preuves s’observent à partir de décisions, de contrôles et de reprises
La révision testée, le périmètre et l’aide reçue donnent du sens à l’observation
La prochaine responsabilité s’éprouve sur un cas différent