Atlassian : Jira et Confluence

Genesis lit et écrit dans le Jira et le Confluence du client — ses tickets, ses pages, son compte de service. Les lectures sont ordinaires. Les écritures sont des propositions : Genesis ne dépose jamais un commentaire, un temps passé, une transition ou une modification de page sur le système d'un client sans qu'un humain distinct ait d'abord approuvé cette écriture précise.

Deux niveaux peuvent posséder un site. Un locataire dispose d'une connexion Atlassian, utilisée par tout ce qui se trouve en dessous. Un produit — le niveau de regroupement sans dépôt git situé au-dessus des projets — peut au contraire pointer vers son propre site : son hôte, son compte de service, son jeton. Cela existe parce que le travail d'un même locataire peut couvrir plusieurs clients, et que le commentaire destiné au ticket d'un client ne doit jamais atterrir dans le Jira d'un autre.

Statut (2026-09) : le niveau produit est désactivé par défaut. La voie locataire est le comportement livré. Les sites de produit sont derrière la fonctionnalité product-atlassian-sites (désactivée par défaut au niveau déploiement) et ne prennent effet que pour un produit explicitement lié. Un locataire sans produit lié n'acquiert aucun comportement nouveau.

1. Guide opérateur

1.1 Les trois fonctionnalités

Atlassian est contrôlé par trois entrées du catalogue de fonctionnalités, chacune avec les deux niveaux habituels : un bit de déploiement dans les valeurs de release (services.core.features.<clé>.enabled) et un interrupteur par locataire dans Paramètres → Fonctionnalités. Ce ne sont plus des clés de configuration plateforme depuis la consolidation de 2026-09 : un config_set sur les anciens noms est désormais refusé et renvoie vers la fonctionnalité.

Le défaut locataire est « activé » pour les trois : activer une fonctionnalité au niveau déploiement l'active donc pour chaque locataire qui ne s'en est pas retiré — exactement ce que donnait l'unique ligne de configuration plateforme. Un administrateur de locataire peut maintenant s'en retirer sans déploiement, et un interrupteur locataire illisible échoue en position FERMÉE (avec une demande d'attention) au lieu de supposer « activé ».

1.2 Lier le site du locataire

Une connexion par capacité (WorkItem pour Jira, KnowledgeBase pour Confluence), portant l'hôte et l'adresse e-mail du compte agissant ; plus un identifiant — le jeton d'API de ce compte. Atlassian Cloud s'authentifie en email:jeton : une connexion sans e-mail n'est donc pas une configuration partielle, c'est un appel authentifié en tant que quelqu'un d'autre. Le résolveur la refuse au lieu de l'envoyer.

1.3 Lier un produit à son propre site

product_atlassian_site_set (ou PUT /api/v1/products/{id}/atlassian-site) prend un hôte, un e-mail agissant et un jeton d'API, stocke le jeton comme identifiant de portée produit, et y pointe le produit. product_atlassian_site_get montre la liaison sans le jeton ; product_atlassian_site_delete supprime les deux.

Trois propriétés méritent d'être connues avant d'en créer une :

• Le drapeau doit être activé d'abord. Créer une liaison pendant que le niveau est éteint est refusé : un produit lié ne retombe jamais sur le site du locataire, la liaison prendrait donc effet comme une panne.
• Désactiver le drapeau n'est pas un retour en arrière. Un produit lié avec le drapeau désactivé refuse tous les appels Atlassian (product_site_disabled). Le retour en arrière consiste à supprimer la liaison.
• Le même hôte est autorisé, le même compte ne l'est pas. Un produit peut se trouver sur l'hôte Atlassian du locataire, à condition d'utiliser un compte différent avec son propre jeton. C'est tout l'objet de ce niveau : l'identifiant est résolu par identité, jamais par hôte, si bien que les deux ne peuvent jamais être confondus.

1.4 Ce que fait une écriture produit

Toute écriture vers le site propre d'un produit est mise en attente d'approbation humaine, quelle que soit la politique de la connexion du locataire. Un locataire qui a ouvert ses propres écritures n'a rien dit du système d'un autre client, et un consentement pour l'un n'est pas un consentement pour l'autre.

1.5 Approuver une écriture en attente

L'approbateur voit le contenu proposé et vers quel site il part — l'hôte et le compte agissant sont nommés sur la demande. Approuver exécute l'écriture ; rejeter l'abandonne.

Si le site a changé entre l'approbation et l'exécution — repointé, ré-identifié, ou compte agissant remplacé — l'écriture est refusée, pas envoyée (park_scope_drift). Un humain a approuvé une écriture précise vers un système précis ; cette approbation ne se transfère pas à un autre. Reproposez l'écriture face à la liaison actuelle.

1.6 Lire un refus

La distinction entre credential_missing, credential_unreadable et credential_unavailable existe parce que l'action suivante de l'opérateur diffère dans chaque cas, et parce qu'un unique « introuvable » envoyait les gens recréer des liaisons qui étaient déjà correctes.

2. Architecture

2.1 Le site tient en trois en-têtes

Chaque appel Atlassian passe par un side-car par locataire. Le site atteint est décidé entièrement par trois en-têtes de requête — le jeton, l'e-mail agissant et l'URL de base. Rien du routage ne change entre la voie locataire et la voie produit ; seule change la ligne qui a fourni ces trois valeurs.

2.2 Une seule élection

Un résolveur unique élit la cible de chaque lecture, de chaque écriture contrôlée et de chaque rejeu approuvé, et le résultat qu'il renvoie est transmis à la fois au fil et au portail d'écriture. C'est important parce que le portail lit une politique d'approbation sur une connexion : si le portail élisait sa propre ligne pendant que le client en élisait une autre, il pourrait décider selon la politique d'un site tandis que l'écriture partirait vers l'hôte d'un autre. Une seule élection rend cela irreprésentable.

2.3 La portée : quatre états, dont deux sont opposés

Un appel déclare sa portée. Tenant est la surface opérateur, locataire par construction. Product nomme un produit. Unbound signifie que la portée a été déterminée et que le projet n'appartient à aucun produit lié — il utilise le site du locataire et ne refuse jamais. Indeterminate signifie que la portée n'a pas pu être déterminée, et il refuse : un appel incapable de dire de quel Jira il parle ne doit pas deviner. Une lecture échouée est toujours Indeterminate, jamais Unbound — confondre les deux est précisément ainsi qu'un incident de base de données devient une écriture silencieuse vers le mauvais site.

2.4 Le fusible

Chaque refus introduit par le niveau produit est conditionné à l'existence d'au moins une liaison chez le locataire. Un locataire qui n'a pas adopté le niveau — y compris lorsqu'une portée d'appel est indéterminée — se comporte exactement comme avant l'existence du niveau. Il n'y a aucun site de produit à se tromper, donc la réponse historique n'est pas seulement sûre : c'est la seule correcte.

2.5 Lié veut dire lié

Dès qu'un produit porte une liaison, il n'y a aucun repli vers le site du locataire. Drapeau manquant, identifiant manquant, identifiant pendant, secret illisible, e-mail agissant vide : tous refusent avant tout appel réseau. Un repli enverrait l'écriture d'un client dans le Jira d'un autre, soit exactement le seul résultat que ce niveau existe pour rendre impossible.

2.6 Les identifiants se résolvent par identité

L'identifiant d'un produit est recherché par (produit, identifiant) — jamais par (hôte, type). C'est ce qui permet à un produit de se trouver sur l'hôte du locataire avec un compte de service différent, et ce qui empêche une liaison de s'authentifier avec l'identifiant d'un autre produit ou du locataire. La réciproque tient aussi : le parcours d'identifiants du locataire exclut explicitement les lignes de produit, si bien que le jeton d'un produit ne peut jamais l'emporter dans une recherche locataire.

2.7 Mise en attente et rejeu

Une écriture en attente conserve les coordonnées nécessaires à son exécution ultérieure, plus une empreinte du site pour lequel elle a été autorisée — hôte, identifiant, compte agissant, et pour un produit la version de ligne de sa liaison. À l'approbation, le site est résolu à nouveau et comparé à l'empreinte ; une différence refuse au lieu d'envoyer. Une empreinte ne compare que les parties qu'elle porte réellement, de sorte que les approbations créées avant l'existence de l'empreinte se rejouent exactement comme auparavant.

Les mises en attente produit portent en outre leur propre discriminant de source. Un binaire antérieur au niveau produit lit une telle mise en attente comme étrangère et ne la rejoue jamais — après un retour arrière, la proposition est abandonnée plutôt qu'envoyée vers le site du locataire.

2.8 Supprimer des choses

Les liaisons sont protégées par RESTRICT dans les deux sens. Supprimer un produit qui porte encore une liaison est refusé et le dit. Supprimer l'identifiant vers lequel une liaison pointe est refusé aussi : une liaison qui se lit comme liée ne peut donc jamais pointer vers un identifiant qui n'existe plus. L'ordre de démontage est par conséquent : délier le site (ce qui supprime son identifiant), puis supprimer le produit.

2.9 Ce qui est observable

Chaque résolution est comptée selon le niveau dont le site a été élu (tenant ou product), et chaque refus selon son code, de sorte qu'un opérateur voit à la fois l'adoption du niveau et ses modes de défaillance. Chaque appel enregistre une ligne d'attribution nommant le type d'identifiant qui l'a servi — un appel produit attribué comme un appel locataire serait un mensonge sur la piste d'audit.