Intégration API Jira
Nous développons votre connecteur Jira
Nous branchons Jira Cloud à votre produit : le SAV ouvre le ticket depuis le dossier, Done clôture l'intervention dans l'ERP, le client suit sans ouvrir Jira.
- Équipe produit senior
- connecteurs Jira en production
- du cadrage au monitoring
À quoi sert l'API Jira et pourquoi l'intégrer dans votre plateforme ?
Jira est l'outil de suivi de tickets le plus utilisé par les équipes techniques. Son API permet à votre application de créer une issue avec le contexte métier, de suivre les transitions, et de réagir quand le statut change. On l'intègre pour que tout cela vive dans votre produit : ticket SAV ouvert depuis le dossier sans copier-coller, Done qui clôture l'intervention dans l'ERP, bug Engineering créé avec le contexte déjà là, portail client qui affiche l'avancement sans exposer Jira. Même SI : Jira reste l'outil eng, votre application reste le parcours métier.
Ce que Jira change dans votre plateforme
Ticket SAV créé depuis le dossier client
Contrat, commande, logs : l'issue Support naît depuis votre produit. Plus de copier-coller depuis l'ERP vers Jira.
Done qui clôture l'intervention dans l'ERP
La transition devient un événement métier. Le technicien ne resaisit pas : le dossier se ferme dans le même SI.
Bug produit vers Engineering, contexte inclus
Replay, URL, compte : l'issue s'ouvre complète. Pas de titre vide ni de second process de qualification.
Portail client sans exposer Jira
Le client suit son signalement dans votre interface. Jira reste côté eng ; le parcours reste dans votre plateforme.
Ce que ça change dans votre produit
La technique au service d'un résultat mesurable : ticket depuis le dossier, Done qui clôture l'ERP, portail sans exposer Jira.
Le SAV n'ouvre plus Jira à la main
Client, contrat, URL, logs : l'issue naît depuis le dossier. Le temps de qualification tombe avant l'assignation.
L'ERP se met à jour quand Jira avance
In Progress, Done : chaque transition peut ouvrir ou clôturer l'intervention. Pas de double saisie.
Le client suit sans quitter votre produit
Le portail affiche l'avancement. Jira reste l'outil eng, pas le parcours client.
Engineering reçoit le bug déjà contextualisé
Replay, URL, compte : plus de ticket orphelin à reconstruire avant de travailler.
Comment nous livrons votre connecteur Jira
Cadrage
Où Jira entre dans votre produit : SAV, Engineering, portail client, clôture ERP. Cloud ou Data Center, auth, budget points. Tranché avant de coder.
Mapping
Mapping des champs vers vos objets métier, JQL, identifiant unique pour l'upsert. Les pièges webhook (post-function Create) sont listés ici.
Développement
Connecteur branché sur la création depuis le dossier, les transitions et le portail. Webhooks plutôt que polling, HMAC, file, extend 30 jours.
Monitoring
Consommation de points, 429, webhooks expirés, dédup issue.id. Alerte avant le plafond horaire, pas après.
Ce que l'API apporte à votre plateforme
- Créer l'issue depuis le dossier métier
- Contrat, commande, URL, logs dans les champs. Identifiant métier pour l'upsert : plus de ticket orphelin.
- Remonter les transitions vers l'ERP
- Webhooks filtrés par JQL : Done clôture l'intervention. Primary en 30 s, secondary 15 min, retries Cloud.
- Alimenter le portail sans exposer Jira
- JQL sur reporter ou champ compte. Le client lit l'avancement dans votre produit.
- Tenir le quota points en production
- 65 000 points/h palier 1 (Forge, Connect, 3LO). Webhooks plutôt que polling /search, extend OAuth à 30 jours.
Le vocabulaire de l'API Jira
- Points / heure
- Depuis le 2 mars 2026, Forge, Connect et 3LO consomment un quota de points, pas un simple compteur de requêtes. Une lecture coûte 1 point par objet métier. Palier 1 : 65 000 points/heure partagés entre tous les tenants.
- Extend webhook life
- Un webhook enregistré en REST (OAuth) expire à 30 jours. Sans cron d'extend, l'app devient muette. Ce n'est pas un détail d'exploitation, c'est un livrable.
- X-Hub-Signature
- HMAC des webhooks Cloud, documenté 2024+. Data Center : retries souvent absents, HMAC selon version. Un client on-prem n'est pas « la même API ».
- API token vs app
- Le trafic API token n'est pas soumis au quota points. Un script interne en token n'est pas un produit multi-tenant. Ne pas vendre une app Marketplace conçue comme un token.
- jira:issue_created
- L'événement à utiliser à la création. Une post-function sur Create Issue ne déclenche pas le webhook. C'est dans la doc, c'est encore le premier incident de recette.
- external_id
- Votre identifiant métier dans un champ Jira unique. Sans lui, chaque retry crée un doublon. L'upsert se fait sur ce champ, pas sur le résumé.
Les contraintes réelles de l'API Jira
Le 2 mars 2026 a changé le polling
Un JQL de 1 000 issues coûte ~1 000 points. Les apps naïves saturent avant midi UTC. Webhooks, pas un scan /search à la minute. Les tokens internes restent hors quota points.
OAuth : 5 webhooks et 30 jours
Un cron extend est obligatoire. Connect offre 100 webhooks, autre modèle. Oublier l'extend, c'est une app muette sans erreur applicative visible.
Cloud n'est pas Data Center
Retries webhook, HMAC, quotas : le devis les sépare dès la première page. Coller un client on-prem sur un connecteur Cloud n'est pas un changement d'URL, c'est un second projet.
Create et post-function restent silencieux
Utiliser jira:issue_created. La suppression de projet en cascade peut omettre issue_deleted. Ces pièges sont dans la doc Atlassian, pas des légendes d'intégrateur.
Webhooks Jira ou recherche JQL périodique ?
Deux façons de tenir Jira à jour avec votre métier. Depuis le 2 mars 2026, le polling naïf n'est plus un choix de confort.
| Critère | WebhooksTemps réel | Polling JQLCron /search |
|---|---|---|
| Coût points | L'événement utile | 1 point × chaque issue lue |
| Délai | Secondes (primary 30 s) | La période du cron |
| Quota OAuth | 5 webhooks, expire 30 j | Burst + points /search |
| Piège Create | issue_created, pas post-function | Aucun, mais cher |
| Sync initiale | Complétée par un import borné | Souvent le vrai tueur de points |
| Token interne | Webhooks UI / Connect | Hors quota points, pas un produit |
| Le bon cas | Produit, ERP, portail | Script interne ponctuel |
Les deux se combinent derrière votre plateforme (créer depuis le dossier, suivre, clôturer). La sync initiale se chiffre en points. Un webhook sans extend à 30 jours est un polling involontaire.
Ce que nous mesurons sur une intégration Jira
Les autres outils de productivité
Jira se combine plus souvent qu'il ne se remplace. Ces options se discutent au cadrage.
JiraNous développons votre connecteur JiraCette page
SlackL'alerte et l'action, quand le ticket n'a pas encore lieu d'exister.
NotionLa base et le wiki, quand Jira est trop lourd pour l'équipe.
AirtableLe tableur structuré, avant un vrai workflow d'issues.
MetabaseNous développons votre connecteur MetabaseOn combine Jira avec
La stack autour de Jira quand on le branche dans un produit ou un ERP.
Jira : vos questions
On la branche sur vos touchpoints produit : création d'issue depuis le dossier SAV, transitions qui clôturent l'ERP, portail client sans exposer Jira. Techniquement : séparer Cloud et Data Center, choisir l'auth (token interne ou OAuth/Forge/Connect), webhooks JQL plutôt que polling /search, HMAC, file, extend 30 jours, champ métier unique pour l'upsert. La partie sensible n'est pas POST /issue, c'est le parcours produit, le budget points et le piège de la post-function Create.
Non. REST v3 Cloud n'est pas l'API Data Center. Côté Cloud : retries webhook jusqu'à 5 fois, HMAC X-Hub-Signature, quota points depuis le 2 mars 2026 pour Forge, Connect et 3LO. Côté DC : retries souvent absents, HMAC selon version, pas le même modèle de distribution. Un client on-prem n'est pas un changement d'URL. Nous le séparons au cadrage, et nous ne vendons pas une app Marketplace conçue comme un token interne.
Forge, Connect et OAuth 3LO consomment des points par heure, pas seulement des requêtes. Palier 1 par défaut : 65 000 points/heure partagés entre tous les tenants. Une lecture d'objet métier coûte 1 point, une identité 2, un write 1 point de base. Un JQL qui ramène 1 000 issues coûte ~1 000 points. Les API tokens restent sur le burst historique : utiles en interne, pas un produit multi-tenant. Nous estimons la sync initiale avant de la lancer, et nous préférons les webhooks au cron.
C'est le contrat REST OAuth : 5 webhooks par app, par user et par tenant, expiration 30 jours, opération Extend webhook life. Sans cron, l'app devient muette sans 4xx métier. Connect monte à 100 webhooks, autre modèle. Primary : livraison 30 s, 20 en parallèle. Secondary (bulk) : 15 min, 10 en parallèle. Corps > 25 Mo non livré. Nous posons l'extend, la dédup et l'alerte d'expiration dans le livrable d'exploitation, pas dans un runbook oublié.
Un premier flux utile, typiquement la création d'issue depuis votre dossier métier avec le champ de rapprochement, se livre en deux à trois semaines. Une chaîne complète avec transitions vers l'ERP, portail client, plusieurs projets et OAuth Marketplace demande plutôt six à huit semaines. La durée dépend surtout des touchpoints à brancher, du mapping et du budget points. Nous cadrons le périmètre en amont et donnons une estimation ferme avant de commencer.
Un projet d'intégration Jira ?
Parlons-en. 30 minutes pour cadrer où Jira entre dans votre plateforme (SAV, Engineering, portail, ERP) et vous dire franchement ce qui tient sans polling.
Parler de mon projet Jira