Chez Yandex, une équipe QA dotée de 15 000 ₽ par mois confie checklists et autotests à un agent IA

Toute équipe QA a une routine que personne n'aime : ouvrir un ticket, comprendre ce qui a changé dans la PR, rédiger une checklist, écrire les cas de test, les automatiser, puis réparer les tests tombés en CI. L'équipe de test de la page d'accueil de Yandex a décidé de confier une grande partie de ce travail à un agent. Elle a raconté sur Habr comment il est conçu, combien il coûte et où elle s'est cassé les dents.

Du plugin d'IDE à l'événement dans Tracker

La première version vivait dans Roo Code pour VS Code. L'ingénieur ouvrait l'éditeur, choisissait un mode, écrivait « fais une checklist pour la tâche », et l'agent allait lui-même dans Tracker, lisait la PR et produisait le résultat. Cela fonctionnait, mais seuls ceux qui savaient déjà automatiser s'en servaient. Les autres auraient dû monter un environnement et vérifier leurs accès, c'est-à-dire remplacer un travail manuel par un autre.

L'agent a donc été déplacé vers des événements. Quand une tâche passe au statut « Prêt à tester », Tracker envoie un HTTP POST à la CI, qui lance un conteneur avec l'agent, et le testeur ouvre le ticket avec une checklist déjà prête. Il existe un second déclencheur : un mot-clé dans un commentaire, pratique pour relancer la génération après une mise à jour de la PR. Pour les autotests, le schéma est similaire, mais l'agent demande d'abord la confirmation de l'ingénieur et ne crée la PR qu'ensuite. C'est une protection contre le spam.

Des sous-agents plutôt qu'un seul gros prompt

La première version était un monolithe : un seul agent lisait la tâche, analysait la PR, rédigeait et publiait la checklist. Il était lent et coûteux, car tout le contexte voyageait dans chaque requête. Désormais, le processus est découpé en étapes : collecte du contexte, analyse de la PR, génération et publication. Un JSON validable est transmis entre elles.

Le gain est concret. Chaque étape ne voit que le contexte dont elle a besoin, chacune a ses propres logs, et en cas de plantage, un seul job est relancé, pas tout le pipeline.

Pour les autotests, trois étapes ne suffisaient pas. Pour des raisons de sécurité, l'agent n'a pas le droit d'accéder à un navigateur réel, de sorte que les locators du premier brouillon étaient imprécis. La solution : exécuter le test en CI (ce n'est plus un LLM), fournir le rapport à l'agent pour qu'il corrige lui-même les locators, puis relancer. Au total, six étapes, dont deux sont de simples exécutions sans modèle.

Un détail qui agaçait beaucoup de monde : la PR est créée par un robot, et non par un ingénieur. Pour que l'humain puisse affiner les locators immédiatement, le login de l'auteur est transmis tout au long de la chaîne, et à la fin le robot l'ajoute comme co-auteur et propriétaire de la branche.

Skills et banque de mémoire

Les connaissances de l'agent se trouvent à deux endroits, tous deux dans le dépôt. Un skill est une instruction pas à pas, comme pour un junior : que faire, quels modèles utiliser, comment vérifier le résultat. Par exemple, un test avec mocks va dans integration, sans mocks dans e2e, et on n'invente pas de vérifications absentes du cas de test. L'équipe dispose de skills distincts pour la collecte du contexte, l'analyse de PR, l'export des cas depuis le TMS, l'écriture de tests, la revue de code et la réparation des échecs. Plus un skill est étroit, moins l'étape coûte cher et plus elle est stable.

La banque de mémoire répond à la question « comment fait-on chez nous » : un ensemble de fichiers Markdown décrivant la stack, les fixtures, les anti-patterns et les échecs typiques. La règle est simple : on n'y consigne que ce qui servira aux tâches suivantes, sans détails propres à un ticket et sans doublons. La banque consomme aussi des tokens, donc un guide court et à jour vaut mieux que deux cents pages de documents périmés.

Combien ça a coûté

Un budget de 15 000 ₽ par mois a été alloué à l'équipe de cinq personnes. Dépenses mensuelles : 11 600, 9 300, 14 600 et 15 000 ₽. Au quatrième mois, la limite a été entièrement atteinte. C'est pourquoi l'équipe calcule séparément le coût de chaque étape : elle journalise les tokens d'entrée et de sortie et suit où part l'argent. La fin de la section de conclusions est tronquée dans le texte source, si bien que les détails sur le volume de requêtes restent hors champ.

Ce qu'il faut retenir

Le schéma n'est lié ni à Yandex ni à un modèle particulier. Pour le reproduire, il faut une CI avec un déclencheur externe, un compte robot et un runtime d'agents. Le rôle de Tracker peut être tenu par Jira Automation ou Linear Webhooks, celui du tasklet par GitHub Actions ou GitLab CI, et l'orchestration par Claude Code, OpenAI Agents SDK ou LangGraph.

Cinq règles de l'article : figer la révision du code, stocker les instructions à côté du code, découper le travail en étapes avec JSON, compter les tokens par étape et restreindre strictement les accès de l'agent.

Les limites sont aussi énoncées honnêtement. L'agent fournit un brouillon, pas une solution finie. Les scénarios complexes, les cas limites et la logique métier sont vérifiés par un humain, qui décide aussi de merger ou non la PR. Sans accès à la vraie page, les tests passent par un cycle d'auto-réparation supplémentaire. C'est un moyen peu coûteux de préparer la base du testeur, mais pas un remplacement du testeur.