Un agent de recette IA en boîte noire : vérifier sans remplacer la validation
Dans notre analyse chiffrée, un constat s’imposait : avec nos agents de développement, la vélocité a doublé, mais la recette s’est mise à valider en un jour ce qu’elle validait auparavant en huit. Le problème n’est plus de produire. Il est de vérifier ce qui a été produit.
C’est l’objet de la quatrième étape de PACE, Éprouver, et du nouvel agent que nous concevons pour l’outiller : l’agent de recette.
Vérifier n’est pas valider
Dans la plupart des projets, le Product Owner fait deux choses en recette, sans les distinguer :
| Question | Qui | Automatisable ? |
|---|---|---|
| Vérification : « Est-ce conforme à ce qui était demandé ? » | Agent de recette | Oui |
| Validation : « Est-ce bien ce qu’on veut ? » | PO / client décideur | Non |
L’agent ne supprime pas la validation. Il la réduit à une quinzaine de minutes : lire un rapport et arbitrer les anomalies, au lieu de dérouler chaque parcours à la main.
C’est un point de positionnement essentiel : l’agent de recette n’est pas présenté comme le remplaçant du PO, sinon le PO décrochera encore davantage. C’est l’agent qui lui mâche le travail.
L’indépendance vient de la conception
Le biais du développeur qui teste son propre code est bien connu. Il vaut aussi pour une IA : si l’agent qui teste partage le contexte de celui qui a développé, il hérite de ses angles morts.
D’où une règle stricte : la boîte noire. L’agent de recette ne lit que trois choses :
- la spécification du module et son glossaire ;
- les critères d’acceptation de la story ;
- l’application déployée sur l’environnement de recette.
Il n’a accès ni au code source, ni aux merge requests, ni à l’historique de conversation des agents de développement. Contexte séparé, profil séparé.
Les pièges que nous avons anticipés
S’adapter, oui. Contourner, non.
Un agent piloté par un LLM sait s’adapter : un bouton déplacé ne le bloque pas. C’est une force, mais aussi un risque. Contourner un vrai bug en passant par un autre chemin, c’est masquer une régression. L’agent a donc l’obligation de signaler tout écart de parcours, même quand le test aboutit, avec un verdict dédié : « passé avec écart ».
Pas d’oracle, pas de verdict
Sans résultat attendu explicite, un agent finit par inventer le sien. Règle : un critère sans résultat attendu devient une ambiguïté, jamais un verdict. Avant même de tester, l’agent produit la liste des ambiguïtés de la spec.
C’est un sous-produit précieux : il force la maturation du besoin, souvent avant même le développement, et renvoie les questions vers l’étape Aligner.
Le non-déterminisme
Un même test joué deux fois par un LLM peut donner deux verdicts. Nous adoptons donc un modèle hybride : l’exploration se fait en langage naturel, puis les scénarios stabilisés sont figés en scripts Playwright pour la non-régression, rejoués sans LLM, donc sans coût et sans aléa.
Le vrai prérequis : les données
Bien souvent, le blocage n’est pas l’IA mais l’environnement. Pas d’agent de recette fiable sans environnement de recette dédié et jeu de données réinitialisable. C’est pourquoi nous les intégrons dès le socle technique du projet.
Ce que l’agent produit
Pour chaque livraison passée « en recette », l’agent enchaîne quatre compétences :
- De la spec au plan de test : cas nominaux, cas limites, cas d’erreur, et liste d’ambiguïtés.
- L’exécution dans un navigateur, avec preuves à l’appui : captures d’écran, requêtes réseau, logs console.
- Un rapport de recette lisible par un non-technicien en quinze minutes : synthèse, anomalies à arbitrer, écarts, ambiguïtés.
- Le triage des anomalies : tickets reproductibles et dédoublonnés.
Et ce qu’il ne fera jamais :
- prononcer la validation : il rend un avis de conformité, le PO décide ;
- créer un ticket sans validation humaine pendant la phase pilote ;
- modifier une assertion d’un script de non-régression sans revue humaine (seuls les sélecteurs peuvent être réparés automatiquement).
Une équipe d’agents, chacun dans son rôle
L’agent de recette rejoint une équipe d’agents déjà au travail sur nos projets, chacun avec une mission, des garde-fous et ce qui n’est pas de son ressort :
| Agent | Rôle | Ce qu’il ne fait pas |
|---|---|---|
| Product Owner | Transforme le besoin en user stories et critères d’acceptation testables (Gherkin) | S’engager sur un délai |
| Architecte | Pose la structure technique, documente les choix (ADR) | Définir le besoin, implémenter |
| Chef de projet | Cadre les délais, arbitre les priorités | Coder |
| Développeur | Implémente en TDD, ouvre les MR, corrige jusqu’au vert de la CI | Merger en production sans validation humaine |
| Qualité | Relit le code, interprète tests, lint, SAST et couverture | Approuver si les tests échouent |
| Recette | Vérifie en boîte noire l’application déployée | Valider à la place du PO |
La répartition entre qualité et recette est volontairement nette : l’un regarde le code (boîte blanche), l’autre regarde le comportement (boîte noire). Et au-dessus de tous, un humain décide.
En résumé
L’IA a déplacé le goulot d’étranglement du développement vers la recette. Plutôt que de laisser la recette devenir une formalité, nous l’outillons, avec une règle simple : l’agent vérifie, l’humain valide.
Non recetté = non Done. Même quand c’est une IA qui a codé.