Connecteur

Jira

Intégration sortante de ticketing : Vigicap y dépose des tickets.

Vos actions partent dans Jira sous forme de tickets, dans le projet que vous indiquez pour chaque client, avec leur titre et leur description. Le statut du ticket est ensuite relu : une fois le ticket terminé dans Jira, Vigicap propose la clôture de l'action et ne la clôture jamais seul. Aucun niveau ReCyF n'est proposé. Pousser un ticket ne mesure pas la posture d'un client.

Ce qu'il faut créer dans l'outil

L'accès se crée dans Jira, pas dans Vigicap. Vigicap ne demande jamais le mot de passe d'un administrateur : il attend un identifiant d'API que vous créez, que vous voyez, et que vous pouvez révoquer sans nous.

Où le générer

Compte Atlassian → Sécurité → Jetons d'API → Créer. L'URL du site est https://votre-site.atlassian.net. La clé de projet est le préfixe de ses tickets (ex. OPS dans OPS-123).

Rôle minimal

Jeton d'API Atlassian d'un compte applicatif. ÉCRITURE : le jeton porte les droits du compte qui l'a créé — Jira ne cloisonne pas un jeton par projet, donc le compte doit être limité côté Jira aux projets concernés (Browse projects + Create issues) plutôt que le jeton côté Vigicap. LECTURE : le même jeton relit l'issue ; aucune portée distincte n'existe, ce qui est précisément pourquoi la phrase précédente est écrite telle quelle.

Formulation reprise du modèle de rôles de l'éditeur, et vérifiée avant publication.

Ce qu'il faut saisir dans Vigicap

Les champs exacts du formulaire de connexion, dans l'ordre où ils apparaissent. Les valeurs marquées « secret » ne ressortent jamais vers le navigateur : elles sont chiffrées au repos et supprimées à la déconnexion.

Le formulaire commence par l'adresse de l'instance, saisie à part des champs ci-dessous. Le catalogue public ne publie pas encore si ce connecteur en demande une, ni à quoi elle ressemble — cette liste est donc exacte pour tout le reste, et muette sur ce premier champ.

Adresse du compte Atlassian
Jeton d'APIsecret

Le routage par client

Ces champs-ci se renseignent client par client : ils disent sous quel compte de l'outil de ticketing le ticket doit atterrir. Une valeur erronée ne fait pas échouer l'envoi — elle le fait réussir chez quelqu'un d'autre, ce pour quoi Vigicap les vérifie au moment où vous les saisissez.

Clé de projet
Projet dans lequel les tickets sont créés — le préfixe de ses références.
ex. OPS
Type de ticketfacultatif
Par défaut Task. Doit exister dans le schéma de types du projet.
Task

Ce qu'il fait, et ce qu'il ne fait pas

Objectifs ReCyF pré-remplis

Ce connecteur n'alimente aucun objectif ReCyF, et ce n'est pas une lacune : il ne mesure pas la posture d'un client.

Ce qui part vers l'outil

Ce connecteur ÉCRIT : il crée un ticket à partir d'une action du plan.

Ce qui en revient

L'état d'un ticket déjà créé revient : son statut, sa date de clôture, sa dernière activité. Un ticket clos devient une PROPOSITION qu'un consultant valide — jamais une action clôturée d'office. Une agence qui clôt son propre ticket ne doit pas pouvoir se noter elle-même dans le document que lit un auditeur.

Ce qui est lu, ce qui est conservé, combien de temps et avec quels droits : le même registre, connecteur par connecteur, dans l'inventaire des données.

Vérification

Ce connecteur a été écrit d'après l'API documentée de l'éditeur et n'a pas encore été exécuté contre une instance réelle. Il est signalé « Bêta » partout où il apparaît.

Les marques et logos cités appartiennent à leurs titulaires respectifs et identifient les outils avec lesquels Vigicap est compatible — voir les mentions légales.