Intégration Jira Cloud

Acheminez les non-conformités AllyProof vers Jira Cloud - un site par projet Jira, un seuil de gravité configurable par site, et un envoi automatique facultatif à la fin des analyses. Lorsque le ticket Jira se ferme, la non-conformité correspondante passe à l'état résolu dans AllyProof. L'intégration est conçue pour les agences qui gèrent plusieurs sites clients sur plusieurs tableaux Jira depuis une seule connexion.

Ce que fait l'intégration

Routage par site. Une organisation AllyProof se connecte à un site Jira Cloud, mais chaque site analysé est acheminé vers son propre projet Jira. Les non-conformités d'ACME arrivent sur le tableau ACME, celles de BetaCorp sur BETA - sans fourre-tout commun.
Seuil de gravité par site. Décidez site par site quelles gravités remontent vers Jira. La production peut tout envoyer ; la préproduction, les seules non-conformités critiques.
Trois façons d'envoyer. Un bouton Push to Jira pour une non-conformité, sur sa fiche ; un bouton d'envoi groupé Push N to PROJECT sur la page de chaque site ; et un sélecteur dépliable pour choisir précisément les non-conformités à envoyer depuis une analyse.
Envoi automatique facultatif. Activez-le par site, et les nouvelles non-conformités se synchronisent automatiquement vers Jira à la fin de chaque analyse. Vers l'avenir seulement par défaut : activer l'envoi automatique ne déverse jamais l'arriéré historique.
Retour de statut. Lorsqu'un ticket Jira passe à un statut de la catégorie Done, AllyProof marque comme résolue la non-conformité liée. Les autres transitions sont laissées à votre équipe.
Idempotent et à l'abri des boucles. Réenvoyer une non-conformité renvoie la clé Jira existante, jamais un doublon. Les modifications que nous effectuons par l'API sont marquées, afin qu'un webhook entrant déclenché par notre propre écriture ne relance pas la synchronisation.

Conditions préalables

Vous avez le rôle Owner ou Admin dans AllyProof. Les membres peuvent utiliser le bouton d'envoi une fois la connexion établie, mais seul un administrateur peut connecter l'intégration, configurer les règles de synchronisation ou la déconnecter.
Vous disposez d'un site Jira Cloud (votre-org.atlassian.net) et du droit de créer des tickets dans chaque projet visé. Jira Server et Data Center ne sont pas pris en charge actuellement.
Le compte Atlassian utilisé pour la connexion peut accorder les portées suivantes : read:jira-work, write:jira-work, read:jira-user et manage:jira-webhook.

Connecter Jira

Rendez-vous dans Réglages → Intégrations.
Cliquez sur Connect Jira. Vous êtes redirigé vers l'écran de consentement d'Atlassian.
Accordez les portées demandées. Vous revenez sur la page Intégrations, avec une pastille « Connected ».
Une connexion nouvelle démarre avec tous les sites exclus. C'est délibéré : cela évite que l'intégration n'achemine automatiquement tous les sites vers un même projet dès la fin de l'autorisation OAuth. Poursuivez avec Configurer les règles de synchronisation ci-dessous pour activer les sites souhaités.

Configurer les règles de synchronisation

Sur la page Intégrations, la section Sync rules liste chaque site actif de votre organisation sous forme de ligne comportant quatre commandes :

Case du site. Décochée, le site est entièrement exclu de la synchronisation Jira : aucun envoi, manuel ou automatique, n'aura d'effet tant que vous ne l'aurez pas cochée.
Projet Jira. La clé du projet (par exemple ACME, WEB, SCRUM) vers lequel acheminer les non-conformités de ce site. Vous la trouverez dans Jira sous Project Settings → Details. Un site ne peut pas envoyer sans elle : la ligne affiche un avertissement orange si le champ est vide.
Gravités. Sélecteur par site pour Critical, Serious, Moderate, Minor. Seules les non-conformités dont l'impact correspond à l'un des niveaux cochés peuvent remonter vers Jira pour ce site. La plupart des équipes retiennent Critical et Serious, afin que Jira reste concentré sur le travail de correction qui compte.
Envoi automatique. Désactivé par défaut : les nouvelles non-conformités restent dans AllyProof jusqu'à un clic sur Push. Activé, elles sont envoyées automatiquement à la fin de chaque analyse - voir Envoi automatique ci-dessous pour la garantie « vers l'avenir seulement ».

Cliquez sur Save sync rules après vos modifications. Le bouton ne s'active que lorsque quelque chose a changé et que chaque site actif dispose d'une clé de projet.

Envoyer des non-conformités

Bouton par non-conformité

Sur la fiche de n'importe quel problème, cliquez sur Push to Jira. Le bouton est remplacé par un lien direct vers le ticket créé dès la fin de l'appel, généralement en moins de deux secondes. Les chargements suivants de cette non-conformité affichent la clé Jira à la place du bouton. Le bouton est automatiquement désactivé, avec une infobulle, lorsque :

le site est exclu de la synchronisation ;
le site n'a pas de clé de projet Jira configurée ;
la gravité de la non-conformité est inférieure au seuil de ce site.

Envoi groupé depuis un site

Sur la page de chaque site, une fois une analyse achevée, un bloc Jira sync récapitule la relation de ce site avec Jira :

N violations ready to push to PROJECT. Cliquez sur Push N to PROJECT pour envoyer en une fois toutes les non-conformités correspondantes non encore envoyées. Les envois sont cadencés (environ 150 ms d'intervalle) pour rester sous les limites de débit de Jira.
M already linked. Les non-conformités disposant déjà d'un ticket Jira issu d'analyses antérieures sont indiquées par transparence, mais ne sont pas réenvoyées.
All matching violations are in PROJECT. Confirmation discrète lorsqu'il n'y a rien en attente.

Sélecteur par non-conformité

Dans le bloc d'envoi groupé, cliquez sur Choose violations pour déplier une liste à cocher. Chaque non-conformité envoyable y figure avec sa pastille de gravité, sa description, son nombre de pages et ses étiquettes WCAG ; toutes les lignes sont présélectionnées, de sorte que le comportement par défaut correspond à celui du bouton replié. Décochez les lignes à écarter : l'action principale devient Push N selected. Le serveur revalide chaque identifiant au regard de vos règles de synchronisation, afin qu'un onglet resté ouvert ne puisse pas les contourner.

Envoi automatique

Lorsqu'un site a l'envoi automatique activé, chaque nouvelle non-conformité détectée lors d'une analyse et conforme aux règles du site est envoyée automatiquement vers Jira à la fin de l'analyse. Trois garanties :

Vers l'avenir seulement. Activer l'envoi automatique enregistre un horodatage de départ ; seules les non-conformités détectées pour la première fois à partir de cet instant sont éligibles. L'arriéré historique reste du ressort de l'envoi manuel ou groupé : basculer l'interrupteur ne déverse donc jamais 200 tickets d'un coup dans Jira.
Mêmes règles. L'envoi automatique passe par les mêmes filtres de projet, de gravité et d'exclusion que le flux manuel. Si vous durcissez les règles, le changement s'applique immédiatement à l'envoi automatique suivant.
Idempotence. La même clé de dédoublonnage que pour les envois manuels est utilisée : une nouvelle analyse qui redétecte la même non-conformité ne crée jamais de ticket en double.

Désactiver l'envoi automatique interrompt l'automatisation immédiatement. Le réactiver plus tard fixe un nouvel horodatage de départ : la période d'interruption est traitée comme de l'arriéré, et non envoyée rétroactivement.

Retour de statut vers AllyProof

Lorsque la catégorie de statut du ticket Jira passe à Done, AllyProof fait passer la non-conformité liée à l'état resolved. Rien d'autre n'est interprété depuis Jira : nous ne reportons délibérément pas l'état In Progress de Jira vers notre flux de travail, car votre équipe AllyProof peut déjà avoir déplacé le problème depuis le tableau de bord, et une synchronisation bidirectionnelle en temps réel dans cet état intermédiaire est la source classique de divergences.

Authentification, jetons et sécurité

Nous utilisons le flux OAuth 2.0 (3LO) d'Atlassian : aucun jeton d'API, aucun mot de passe partagé.
Les jetons d'accès et de rafraîchissement sont chiffrés au repos (AES-256-GCM) avec une clé gérée côté serveur, avant toute écriture en base.
Les jetons de rafraîchissement d'Atlassian tournent à chaque usage ; nous réenregistrons le nouveau couple de façon atomique, si bien qu'un ancien jeton rejoué est rejeté.
Les webhooks entrants d'Atlassian portent un jeton JWT signé en HS256 avec le secret client de notre application : nous le vérifions avant de toucher au corps de la requête, et nous dédoublonnons sur le triplet événement, ticket et horodatage, afin qu'un rejeu ne réapplique pas un changement de statut.

Déconnecter

Dans Réglages → Intégrations, cliquez sur Disconnect Jira. La connexion est supprimée de façon logique - nous conservons la ligne à des fins d'audit -, les jetons sont révoqués de notre côté, le webhook entrant est désenregistré auprès d'Atlassian, et tous les chemins d'envoi cessent immédiatement de fonctionner. Les liens existants entre non-conformités et tickets restent dans AllyProof comme traces historiques, mais ne se synchronisent plus.

Limites et réserves

Un seul site Jira Cloud par organisation AllyProof. Plusieurs projets au sein de ce site sont pleinement pris en charge, par le routage par site.
Les webhooks dynamiques d'Atlassian expirent au bout de 30 jours. Nous les renouvelons automatiquement, selon une planification : aucune action manuelle n'est nécessaire.
L'envoi groupé est cadencé à environ 150 ms entre les appels et respecte l'en-tête Retry-After d'Atlassian en cas de réponse 429, avec un report exponentiel. Pour de très gros arriérés - plusieurs centaines de non-conformités au premier envoi -, prévoyez une à deux minutes : le lot s'écoule vers Jira en arrière-plan et la page se rafraîchit à la fin.
Les changements de règles de gravité prennent effet au prochain envoi, manuel ou automatique. Les tickets déjà envoyés ne sont pas rappelés rétroactivement si vous durcissez le filtre : la garantie d'idempotence l'emporte volontairement sur un changement de règles a posteriori.
Besoin d'aide pour une configuration de routage particulière, ou confronté à un blocage ou une erreur 403 de Jira ? Ouvrez une demande d'assistance et nous examinerons les journaux ensemble.