Un agent n8n écrit des cas de test : il récupère le cas d’usage dans Pachka et les exigences dans Yandex Wiki

Balancer un cas d’usage à un chatbot et obtenir de bons cas de test, ça ne marche pas : les bugs se cachent dans les détails, et le modèle n’en a pas. Il lui faut du contexte — exigences, tickets, échanges. Et pour fournir ce contexte, il faut des intégrations. L’auteur d’une analyse publiée sur Habr présente une version minimale d’un tel pipeline dans n8n : du message dans le chat de travail jusqu’au cas de test prêt à l’emploi.

Ce que l’on construit et avec quoi

n8n est un constructeur d’agents qui relie les modèles au code, aux gestionnaires de tâches, à la CI et au reste de l’infrastructure. Chaque action est un nœud distinct, et les nœuds s’assemblent en workflow, comme des Lego. Le workflow peut être exporté en JSON. Le code source est ouvert : dans le cloud n8n, on paie l’hébergement et chaque exécution ; sur sa propre infrastructure, c’est gratuit. Il existe plus de 2600 intégrations, on peut donc monter un agent pour la plupart des stacks. Par exemple, générer des cas de test à partir de tickets Jira et de la documentation sur GitHub, avec une recherche via Pinecone.

Le scénario de l’article est plus simple. L’exigence se trouve dans Yandex Wiki, le cas d’usage dans le chat Pachka. La logique tient en quatre étapes :

• l’agent attend un cas d’usage de l’utilisateur dans le chat ;
• il demande via un formulaire l’URL de la page contenant l’exigence, sous forme de commentaire au message ;
• il transmet au modèle le cas d’usage et l’exigence ;
• il renvoie la réponse dans le fil du cas d’usage.

Comment connecter Pachka et Wiki

Côté Pachka, il faut créer un bot et activer un webhook sortant. L’auteur signale trois options : ignorer ses propres messages (pour que le bot ne se déclenche pas lui-même), écouter tous les messages et réagir aux clics sur les boutons. Le système n’affiche le jeton qu’une seule fois, il faut donc le sauvegarder immédiatement. Droits : messages:read, messages:create, threads:read, threads:create et views:write — ce dernier permet à l’utilisateur de transmettre l’URL de l’exigence via un formulaire. L’URL du webhook et la clé de signature sont à renseigner dans le déclencheur n8n.

Il y a un piège. Le bouton Execute n’écoute pas votre URL mais une URL de test, ce qui empêche de vérifier le déclencheur ainsi. Deux solutions : créer un bot de test distinct ou publier le workflow. Dans un workflow publié, les déclencheurs captent les événements d’eux-mêmes, et le résultat apparaît dans l’onglet Executions.

Avec Yandex Wiki, c’est plus compliqué : pas de nœud prêt à l’emploi, mais un serveur MCP fonctionne. Il faut une application OAuth avec le droit wiki:read, un jeton obtenu via le lien d’autorisation contenant votre ClientID, et l’identifiant de l’organisation. Pour « Yandex 360 pour les entreprises », c’est X-Org-ID ; pour Yandex Cloud Organization, X-Cloud-Org-ID. Dans Credentials de n8n, on crée une entrée de type Multiple Headers Auth avec deux en-têtes : Authorization et l’en-tête de l’organisation.

Ensuite, deux options. Le nœud carré MCP Client appelle l’outil directement. Le nœud rond MCP Client Tool se branche sur le nœud du modèle, et c’est le modèle qui décide quoi demander. L’auteur a choisi l’appel direct : HTTP Streamable, endpoint mcp.wiki.yandex.net, outil GetPageById. Le point délicat est l’ID de la page : on ne peut l’obtenir que via l’API de Wiki, par une requête sur le slug, par exemple avec curl, le jeton et l’en-tête de l’organisation.

Le résultat et les limites

Les données circulent entre les nœuds en JSON ; on accède à la sortie du nœud précédent via $json.nom_de_la_variable. Le plus simple pour trouver les noms des variables est de consulter l’onglet Executions après n’importe quelle exécution, même ratée. Résultat : le bot reçoit le cas d’usage, demande le lien vers l’exigence et renvoie le cas de test dans le fil. L’auteur a publié le workflow prêt à l’emploi sur GitHub, au format JSON.

Pour l’instant, il s’agit d’une démonstration de possibilités, non d’une évaluation de la qualité. Aucune métrique : on ne sait pas dans quelle mesure les cas de test générés coïncident avec ceux écrits à la main ni combien d’erreurs ils laissent passer. L’auteur lui-même met en garde contre les écueils : l’outil ne trouvera pas les exigences qui n’existent que dans la tête du client, ne supprimera ni les hallucinations ni les vérifications manuelles. Ils feront l’objet du prochain article.

Que faire en pratique. Si votre équipe utilise déjà Pachka et Wiki, le workflow peut être reproduit en une soirée. Pour un premier essai, l’appel direct à MCP suffit : il est plus prévisible que de laisser le modèle choisir l’outil (c’est notre avis, l’article ne propose pas cette comparaison). Conservez les identifiants dans Credentials, et non dans les nœuds eux-mêmes. Vérifiez le résultat sur 5 à 10 cas d’usage réels et comparez-le avec ce qu’aurait écrit un testeur. Ce n’est qu’ensuite qu’il faut décider si un tel agent a sa place dans le processus.