MAYAK assemble un pipeline QA de 58 blocs et détecte 9 pièges sur 10 dans un cahier des charges

L'auteur du projet MAYAK a construit un pipeline qui mène un cahier des charges jusqu'à l'exécution des tests en passant par 58 blocs spécialisés. Sur un cahier des charges synthétique contenant dix défauts introduits volontairement, l'automate en a détecté neuf. Le dixième a été trouvé par un humain, mais grâce au questionnaire établi par la machine. En 90 secondes, le système a généré 26 questions pour les parties prenantes et repéré 20 zones grises. En 26 minutes, il a écrit 37 scénarios BDD.

La documentation avant les clics

Le nom du projet donne l'ordre de travail : on clarifie d'abord les exigences, puis on écrit et on exécute les tests. La chaîne se présente ainsi : « cahier des charges → canonisation → conception de tests → exécution ». À en juger par le nom de l'étape, la canonisation ramène un texte d'exigences hétéroclite à une forme unique et structurée. La conception de tests s'appuie ensuite sur cette forme. La logique est claire : des tests dérivés d'un cahier des charges flou héritent de son flou et ne font que le masquer sous un format soigné.

Le projet appartient à une catégorie de systèmes en pleine croissance, où le LLM ne travaille pas avec un seul prompt mais au sein d'un long pipeline d'étapes étroites. Ici, il y en a 58.

Des portes de confiance plutôt que des suppositions

Le principal problème des modèles de langage en conception de tests est leur tendance à combler les manques par des précisions plausibles. Le cahier des charges dit : « la page doit s'ouvrir rapidement ». Le modèle sort volontiers « pas plus de 2 secondes » et en fait un critère d'acceptation. L'auteur de MAYAK colmate cette brèche avec deux règles :

• chaque critère d'acceptation est ancré dans une citation du document source : pas de citation, pas de critère ;
• une zone grise devient une question posée aux parties prenantes, et non une valeur devinée.

Un troisième point relève de l'économie. Les exécutions répétées sont gratuites grâce au cache. Avec 58 blocs, c'est loin d'être anodin : le cahier des charges est corrigé au fil des réponses aux questions, et sans cache, chaque itération serait facturée de nouveau.

Ce qu'a montré l'exécution

Le test a porté sur un cahier des charges synthétique, dans lequel l'auteur avait glissé à l'avance dix « maladies ». Résultats tirés de l'annonce :

• l'automate a détecté 9 pièges sur 10 ;
• le dixième a été trouvé par un humain, à partir du questionnaire de la machine ;
• 26 questions pour les parties prenantes ont été générées en 90 secondes ;
• 20 zones grises ont été identifiées ;
• 37 scénarios BDD ont été prêts en 26 minutes.

Ces chiffres sont à lire avec des réserves. Les pièges ont été imaginés par l'auteur lui-même, le document est synthétique et il n'y a eu qu'une seule exécution. C'est une démonstration de faisabilité, pas un benchmark. Les cahiers des charges réels sont généralement plus longs, plus contradictoires et parfois rédigés par des gens qui ne savent pas eux-mêmes ce qu'ils veulent. L'auteur promet de détailler où la plateforme se trompe et ce qui reste inachevé. Ces sections figurent dans le texte complet sur Habr ; l'annonce n'en donne aucun détail, et il est donc impossible d'évaluer pour l'instant l'ampleur des erreurs.

Le cas du dixième piège est à part. Le système ne l'a pas résolu seul, mais son questionnaire a aidé l'humain. En pratique, ce n'est pas une faiblesse, c'est un schéma normal : la machine réduit le champ de recherche, l'humain tranche.

Ce qu'on peut en retenir

On peut reprendre plusieurs techniques du projet sans le copier intégralement :

• Faites tourner votre pipeline sur un document contenant des défauts introduits à l'avance et calculez la part de défauts détectés. Sans cet étalon, les discussions sur la qualité restent des opinions.
• Exigez du modèle une citation-source pour chaque critère d'acceptation et rejetez automatiquement tout ce qui n'en a pas.
• Mesurez non seulement le nombre de scénarios générés, mais aussi la part de questions auxquelles les parties prenantes ont réellement répondu. Un bon questionnaire ne sert à rien si personne n'y répond.
• Mettez en cache les résultats intermédiaires des blocs, afin que la correction d'un seul paragraphe du cahier des charges ne relance pas tout le pipeline.
• Gardez un humain pour la revue finale. Neuf sur dix sur un document synthétique ne garantissent pas encore le même résultat sur un document de production.

Si vous avez accumulé une archive de cahiers des charges dont les problèmes ont été identifiés après coup, c'est un jeu de test tout prêt pour cette approche.