Intégrations : Jira, Xray, Azure DevOps, Slack et Telegram

Nexus Studio se connecte à cinq services : Jira Cloud, Xray Cloud, Azure DevOps, Slack et Telegram. Chacun est désactivé jusqu'à ce que vous l'activiez, et chacun est joint directement depuis votre machine, jamais via nos serveurs. Cette page explique ce que chacun fait, les clés qu'il lit, et ce qu'il ne fait jamais.

Par l'équipe Nexus Studio, Verdict System LLC. 9 octobre 2026.

Comment fonctionne chaque intégration

• Désactivé jusqu'à ce que vous l'activiez. Chaque service possède son propre commutateur : JIRA_ENABLED, XRAY_ENABLED, AZURE_BOARDS_ENABLED, SLACK_ENABLED et TELEGRAM_ENABLED. Chacun est à false par défaut.
• Directement depuis votre machine. Le moteur appelle l'API propre à chaque service depuis la machine qui exécute les tests. Rien ne transite par nos serveurs, et nous ne voyons jamais vos tickets, alertes ou résultats.
• Les clés restent dans l'espace de travail. Les jetons et les clés sont des lignes dans le fichier .env de l'espace de travail, sur votre disque. Les Paramètres, sous Intégrations, permettent de les modifier et affichent chaque jeton, clé et webhook masqué.
• Les exécutions de sandbox restent à l'écart. Une exécution de sandbox est un test en cours de construction, pas une anomalie : elle ne crée, ne commente ni ne ferme jamais de ticket.

Un ticket par test, tant qu'il reste en échec

Jira et Azure Boards suivent le même cycle de vie. Le ticket est rattaché au test, et non à l'exécution, de sorte qu'un test qui échoue chaque nuit correspond à un seul ticket avec un historique, et non à un nouveau ticket chaque nuit.

1. Le premier échec ouvre un ticket. Une exécution qui se termine par BREACHED, BREACHED_FLAKY, CHAOS_BREACHED ou TIMEOUT ouvre un ticket pour ce test, avec l'erreur et la capture d'écran de l'échec en pièce jointe.
2. Un nouvel échec y ajoute un commentaire. Tant que ce ticket est ouvert, l'échec suivant y ajoute un commentaire, avec la nouvelle capture d'écran en pièce jointe. Deux navigateurs qui échouent en même temps l'ajoutent au même ticket.
3. Un succès complet le clôture. Lorsque le test réussit sans encombre sur chaque navigateur d'une exécution, le ticket reçoit un commentaire l'indiquant et passe à l'état terminé. Si le workflow ne comporte pas une telle transition ou un tel état, il reçoit uniquement le commentaire.
4. Un échec survenant après cela ouvre un nouveau ticket. Il en va de même pour un échec dont le ticket a été supprimé ou déplacé.

Pièces jointes : la capture d'écran uniquement, par défaut. La trace Playwright et le journal d'exécution ne sont également joints que si vous l'activez avec NEXUS_ISSUE_ATTACH_TRACE=true dans les Paramètres, car ils peuvent contenir des données de session : cookies, en-têtes d'autorisation et mots de passe saisis. Chaque fichier est joint jusqu'à 10 Mo.

FLAKY ne crée jamais rien : une exécution qui a échoué puis réussi lors d'une nouvelle tentative n'est pas un bug. Il en est de même pour BLOCKED, UNREACHABLE, CRASHED ou une erreur de configuration, qui concernent l'environnement et non votre application (comment les verdicts sont déterminés). La correspondance entre les tickets et les tests est conservée dans evidence/integrations/issue-map.json, au sein de l'espace de travail.

Jira Cloud

• Connexion : l'adresse e-mail de votre compte Atlassian et un jeton API, créé sur id.atlassian.com. Dans les Paramètres, sous Intégrations, collez n'importe quel lien issu de votre site Jira : le Studio conserve le site et la clé du projet. L'adresse du site, JIRA_BASE_URL, doit être en https. Vérifier la connexion les teste sans rien créer.
• Tickets : un Bug dans JIRA_PROJECT_KEY, suivant le cycle de vie ci-dessus. En cas de succès complet, le ticket passe par la transition spécifiée dans JIRA_DONE_TRANSITION, Done par défaut, identifiée par son nom sans tenir compte de la casse.
• Pas de doublons : si un Bug avec le même résumé a été créé au cours des dernières 24 heures, aucun second bug n'est créé.
• Manuellement : le casier des preuves (Evidence Locker) peut transmettre un échec à Jira lorsque vous le décidez.

Xray Cloud

Avec XRAY_ENABLED=true, chaque exécution de nexus ci importe son XML JUnit dans Xray Cloud en tant que Test Execution, dans XRAY_PROJECT_KEY, ou dans JIRA_PROJECT_KEY si ce dernier est vide, et sous le Test Plan indiqué dans XRAY_TEST_PLAN_KEY si vous en avez défini un.

• Connexion : une paire de clés d'API, XRAY_CLIENT_ID et XRAY_CLIENT_SECRET, créée dans Jira sous Applications, Xray, Paramètres globaux, Clés d'API.
• Ce qui est transmis : le fichier JUnit de cette exécution, et rien d'autre. Un fichier JUnit résiduel d'une exécution antérieure n'est jamais importé.
• N'interrompt jamais l'exécution : si l'importation échoue, le journal d'exécution en explique la raison en une ligne, avec le secret masqué.

Azure DevOps : Boards, Test Plans et Pipelines

Un jeton d'accès personnel (PAT) et un projet, dans AZURE_DEVOPS_ORG_URL (https://dev.azure.com/<org> ou https://<org>.visualstudio.com) et AZURE_DEVOPS_PROJECT. Le PAT est envoyé uniquement aux propres hôtes d'Azure DevOps et n'apparaît jamais dans une ligne de journal. Dans les Paramètres, sous Intégrations, Connecter Azure DevOps vérifie le projet ainsi que le type d'élément de travail, sans rien créer.

• Azure Boards : avec AZURE_BOARDS_ENABLED=true, un échec ouvre un élément de travail de type AZURE_BOARDS_WORK_ITEM_TYPE, Bug par défaut, en suivant le cycle de vie ci-dessus. En cas de succès total, il passe à l'état défini dans AZURE_BOARDS_DONE_STATE, Resolved par défaut ; un processus qui refuse cet état reçoit uniquement le commentaire. Le PAT nécessite Éléments de travail (Lecture & écriture). L'Evidence Locker peut également envoyer manuellement un échec à Azure Boards.
• Azure Test Plans : le fichier azure-pipelines.yml généré par l'écran CI/CD publie le fichier XML JUnit de l'exécution avec la tâche PublishTestResults@2, afin que chaque exécution de pipeline apparaisse sous Test Plans, Runs.
• Azure Pipelines : nexus ci-remote --provider=azure met en file d'attente une exécution du pipeline dans AZURE_PIPELINE_ID, l'attend et rapatrie son XML JUnit sur cette machine. Le PAT nécessite Build (Lecture & exécution) pour cela.

Slack

• Connexion : une URL de Webhook entrant, dans SLACK_WEBHOOK_URL. Les Paramètres disposent d'un bouton Envoyer un message de test.
• Ce qu'il reçoit : des messages Block Kit : le résumé de l'exécution et, avec NEXUS_SLACK_NOTIFY=true, un message par test échoué, instable, de chaos ou de régression visuelle. Un message concernant un échec renvoie vers son ticket Jira lorsqu'il en existe un.
• Manuellement : l'Evidence Locker peut publier un résumé textuel de l'échec sur Slack. Slack ne reçoit aucun fichier.

Telegram

• Connexion : votre propre bot, créé une fois avec @BotFather, dans TELEGRAM_TOKEN. Dans les Paramètres, Connecter par QR associe votre discussion et renseigne TELEGRAM_CHAT_ID. Il n'y a pas de bot partagé.
• Ce qu'il reçoit : des alertes en cas d'échec, une par test avec NEXUS_TELEGRAM_NOTIFY=true, ainsi que les rapports et fichiers que vous choisissez de partager depuis le Studio.
• Avant de l'activer : Telegram peut recevoir des fichiers, tels que des rapports et des PDF, et ils sont transmis aux serveurs de Telegram. Dans un environnement réglementé, consultez d'abord votre équipe de conformité.

Les clés

Chaque clé correspond à une ligne dans le fichier .env de l'espace de travail. Les Paramètres permettent de toutes les modifier.

Dans un pipeline, les mêmes clés, toutes sauf AZURE_PIPELINE_ID, sont les variables secrètes du pipeline, et une clé que vous laissez non définie maintient son service désactivé (secrets dans CI/CD).

Questions

Nexus Studio a-t-il accès à mes données Jira ou Azure DevOps ?

Non. Le moteur communique avec Jira, Xray, Azure DevOps, Slack et Telegram depuis votre machine, avec vos clés. Aucune de ces données ne transite par nos serveurs.

Un test instable (flaky) ouvrira-t-il un ticket ?

Non. FLAKY ne consigne rien. BREACHED_FLAKY le fait : l'échec lui-même était incohérent, et une nouvelle tentative ne le masque pas.

Un test a échoué 30 fois cette semaine. Combien de tickets cela représente-t-il ?

Un seul, avec un commentaire et une nouvelle capture d'écran pour chaque échec après le premier, jusqu'à ce que le test réussisse sans erreur sur chaque navigateur.

Puis-je utiliser Jira et Azure Boards en même temps ?

Oui. Chacun conserve son propre ticket par test.