Sortir de Jira en 2027 : mettez vos tickets là où travaillent vos agents

Votre équipe fait déjà travailler des agents de code (Claude Code, OpenCode, Codex, Cursor) et Atlassian vous pousse à quitter Jira Data Center avant 2029. Cet article répond à une question précise : où doit vivre le ticket quand ce sont des agents qui font le travail ? Notre réponse : dans le repo, à côté du code, modifié dans le même commit. Le backlog d'ingénierie devient un dossier de fichiers Markdown versionnés, écrits par une CLI ou un serveur MCP, et un board généré sert le métier. Ce modèle vise les équipes déjà outillées en agents ; une équipe sans agent a mieux à faire avec un tracker de forge. Les scores qui suivent sont une évaluation argumentée, pas une mesure.

Quand Jira Data Center s'arrête-t-il, et combien coûte Jira Cloud ?

Atlassian a publié le calendrier lui-même. Les produits Data Center concernés arrivent en fin de vie le 28 mars 2029 à 23h59 PST : les abonnements et les apps Marketplace associées expirent, et les produits passent en lecture seule¹. Les nouveaux clients ne peuvent plus acheter d'abonnement Data Center depuis le 30 mars 2026 ; les clients existants peuvent acheter et étendre jusqu'au 30 mars 2028¹. Bitbucket et Bamboo Data Center échappent à la fin de vie : leurs clients reçoivent une licence hybride qui couvre aussi Bitbucket Cloud¹. En septembre 2025, dans le billet « Ascend to the cloud » déposé auprès de la SEC, Atlassian justifiait ce choix par le fait que 99 % de ses plus de 300 000 clients bénéficiaient déjà de sa plateforme Cloud².

Côté Cloud, les nouveaux prix catalogue s'appliquent depuis le 13 octobre 2026. Dans la grille d'Atlassian, Jira Standard passe de 9,05 à 9,70 dollars par utilisateur et par mois sur la tranche de 1 à 100 utilisateurs, et Jira Premium de 18,30 à 19,60 dollars, soit environ 7 % de hausse dans les deux cas (notre calcul)³. Atlassian ne publie pas de pourcentage global. S'y ajoute, à partir du 3 décembre 2026 pour la plupart des compteurs, la facturation à l'usage des crédits Rovo, des étapes d'automatisation et des résolutions par agent IA, annoncée le 1er septembre 2026. Pour la plupart des clients, le dépassement est activé par défaut : il revient aux administrateurs de facturation de le couper ou de plafonner chaque compteur⁴.

Pour un DSI, la conséquence est une migration forcée. C'est aussi le seul moment où l'on peut changer de modèle sans payer la migration deux fois.

Pourquoi un agent travaille mieux avec un ticket dans le repo

L'argument le plus solide vient d'un praticien. Dans « We Replaced Jira With Markdown Files » (publié le 11 août 2026, mis à jour le 22 octobre), David Golverdingen, AI Engineering Lead chez Warmtebouw, raconte qu'il branchait Claude sur Jira par un serveur MCP⁵. Ça fonctionnait, mais chaque session restait lente et maladroite : l'agent subissait un schéma étranger et ne voyait pas le ticket pendant qu'il lisait le code. L'auteur en tire un diagnostic de context engineering : il faut placer le contexte là où l'agent regarde déjà.

Son équipe a donc créé un dossier tickets/ dans chacun de ses dix repos (TypeScript, C#, Java, PowerShell). Un ticket y est un fichier Markdown à frontmatter YAML (id, type, titre, statut, priorité, taille, assignee, tâches) et à intertitres fixes, d'Objective à Work Log en passant par Acceptance Criteria, Implementation Plan et un diagramme Mermaid⁵. Chaque champ est validé par schéma, et un hook pre-commit puis la CI rejouent la validation, si bien qu'un ticket mal formé n'atteint jamais la branche principale. La règle qui tient l'ensemble est écrite noir sur blanc : « nobody edits these files by hand ». Toutes les écritures passent par une CLI d'opérations typées qui horodate, refuse les transitions invalides et garde le fichier valide par construction⁵.

Le board Kanban agrège les repos et n'est qu'une projection. Seul l'ordre des cartes vit hors de git, dans Firestore. Un serveur MCP maison, WBTickets, expose 20 outils de lecture et d'écriture : un collègue sur claude.ai, sans checkout ni git, crée et met à jour des tickets⁵.

Bilan après sept mois : 15 projets, 10 repos, 165 tickets actifs, 12 personnes sur le board dont des non-développeurs, et plus de licence Jira. Golverdingen chiffre l'ancienne licence à environ 2 000 euros par an pour un outil utilisé « maybe 5% », et précise que ce coût n'était pas la raison du départ⁵. Le gain qu'il retient : l'agent qui fait le travail consigne les écarts dans le même commit que le code, et le board décrit ce qui a été livré plutôt que ce qui était prévu. Il chiffre aussi le passif : environ une heure de maintenance par semaine sans nouvelle fonctionnalité, assurée par l'équipe qui utilise l'outil chaque jour. Et il borne lui-même la portée de l'expérience : « Nobody sane is rebuilding their ERP this way. »⁵

Le ticket devient le contexte de l'agent. Un ticket hors du repo coûte un appel d'outil, un schéma à apprendre et un écart inévitable entre ce qui est écrit et ce qui est fait. C'est la suite logique du passage du spec-driven à l'issue-based : quand l'agent travaille à partir d'écarts signalés, l'écart doit vivre là où il lit.

Quels outils mettent le backlog dans le repo ?

Backlog.md

Backlog.md, d'Alex Gavrilescu (MrLesk), sous licence MIT, est le format le plus proche du Markdown dans le repo prêt à l'emploi : une tâche par fichier dans un dossier backlog/, un board en terminal (backlog board) et un board web local (backlog browser)⁶. Les agents passent par défaut par la CLI ; un serveur MCP reste disponible pour qui le préfère. Son README affirme que presque tout son code est écrit par des agents qui travaillent via Backlog.md lui-même, et la commande backlog agents --update-instructions met à jour CLAUDE.md, AGENTS.md, GEMINI.md et les instructions Copilot⁶. Dans « A year of building Backlog.md » (7 juillet 2026), l'auteur explique que l'atout de départ était une persistance des tâches qui survit aux compactions de contexte, et que l'outil lui sert aujourd'hui autant à comprendre ce que font les agents qu'à les guider⁷. Le dépôt comptait 7 372 étoiles le 13 novembre 2026.

Beads

Beads, de Steve Yegge (MIT), est le tracker natif agent le plus suivi : 28 710 étoiles le 13 novembre 2026, dépôt désormais hébergé sous l'organisation gastownhall⁸. C'est un graphe de dépendances interrogé en ligne de commande (bd ready, bd update <id> --claim, bd close), avec sortie JSON, identifiants hachés qui évitent les collisions entre agents et une compaction qui résume les tâches fermées pour économiser le contexte⁸. Beads ne stocke pas du Markdown : depuis les versions 0.56 et 0.58 (février et mars 2026), Dolt, une base SQL versionnée, est son seul backend, et le fichier JSONL n'est plus qu'un export⁸.

Yegge est aussi le critique le plus virulent des plans Markdown. Dans « Introducing Beads » (13 octobre 2025), il raconte avoir découvert « six hundred and five markdown plan files in varying stages of decay » dans son dossier plans/⁹. Trois semaines plus tard, dans « Beads Blows Up » (6 novembre 2025), il reconnaissait que « Beads has remained very, very buggy »¹⁰. Beads sert de registre de travail à Gas Town, son orchestrateur multi-agents¹¹.

Task Master

Task Master (claude-task-master, d'Eyal Toledano, 28 359 étoiles le 13 novembre 2026) transforme un PRD en graphe de tâches stocké dans .taskmaster/tasks/tasks.json et exposé par un serveur MCP¹². Son jeu complet de 36 outils consomme environ 21 000 tokens. Le README annonce ce mode comme défaut, mais la documentation de configuration et le code du serveur chargent le mode « core » (7 outils, environ 5 000 tokens) quand rien n'est configuré : c'est le code qui fait foi¹². Deux points à peser avant de l'adopter : la licence est MIT assortie d'une Commons Clause, et la dernière version publiée (0.43.1) date du 31 mars 2026.

git-bug

git-bug stocke les issues comme objets git, séparés de l'historique des fichiers : rien n'est ajouté à l'arborescence du projet, la synchronisation passe par les remotes, et des ponts importent et exportent depuis GitHub, GitLab, Jira et Launchpad¹³. La version 0.11.0 est sortie le 22 septembre 2026, seize mois après la précédente, et la 0.12.0 a suivi le 7 novembre¹³. L'outil est robuste et distribué (licence GPL-3.0), mais un agent qui lit le système de fichiers ne voit pas les issues, et nous n'avons trouvé aucun serveur MCP officiel.

Spec Kit et OpenSpec

Spec Kit de GitHub (149 648 étoiles) et OpenSpec de Fission AI (74 784 étoiles, MIT), relevés le 13 novembre 2026, génèrent des artefacts Markdown (spécification, plan, tasks.md)¹⁴¹⁵. OpenSpec range chaque changement dans openspec/changes/<id>/ (proposal.md, specs/, design.md, tasks.md), puis l'archive en fusionnant ses deltas dans les specs de référence¹⁵. Ils remplacent le ticket détaillé ; le backlog et la vue portefeuille restent à couvrir. Ils se combinent bien avec Backlog.md ou un tracker léger : le ticket dit quoi et pourquoi, la spec dit comment. Notre comparatif des méthodes de développement avec agents les lit en détail.

Que valent les trackers classiques pour un agent ?

Tous les grands outils exposent désormais un serveur MCP. Ils se départagent sur la délégation à des agents et sur la distance au code.

• GitHub Issues : on assigne une issue à Copilot comme à un humain ; Copilot travaille, ouvre une pull request et demande une revue. Limite documentée : après l'assignation, Copilot ne voit plus les commentaires ajoutés à l'issue, et la documentation demande de les poster sur la pull request¹⁶.
• Linear : serveur MCP officiel lancé le 1er mai 2025, avec aujourd'hui un endpoint mcp.linear.app/mcp/readonly qui n'expose que des outils de lecture¹⁷¹⁸. Une issue se délègue à Cursor, Copilot, Codex, Devin, Warp, Sentry ou Factory, ou à l'agent maison Linear Agent¹⁸. Depuis le 13 août 2026, les espaces Enterprise peuvent faire vérifier par Okta l'identité des employés qui se connectent au MCP depuis un agent Anthropic¹⁹.
• GitLab : le serveur MCP intégré à l'instance (/api/v4/mcp) est en disponibilité générale depuis GitLab 19.5²⁰. Les outils work items (get_work_item, list_work_items, save_work_item), arrivés en bêta dans la 19.4, couvrent issues, epics, tâches et incidents²¹. Sans réglage, les outils de lecture sont pré-approuvés et ceux d'écriture demandent une validation. On peut aussi assigner une issue à un agent externe (Claude Code, Codex, Amazon Q, Gemini) via un compte de service, en Premium et Ultimate, derrière un feature flag²². Pour une instance privée, l'agent parle à votre GitLab, pas à un SaaS tiers. GitLab pousse la même logique plus loin avec Orbit et son graphe de contexte.
• Plane (open source) : serveur MCP officiel sous licence MIT, hébergé ou lancé en stdio contre une instance auto-hébergée²³. Depuis mai 2026, on assigne un work item à l'agent Cursor²⁴.
• YouTrack : serveur MCP intégré depuis la version 2025.3, avec OAuth depuis la 2026.2. La documentation utilisateur indique que les outils créent et modifient des données, avec un filtre pour les restreindre à la lecture ; une page de la documentation développeur les dit encore en lecture seule. Vérifiez sur votre version²⁵.
• OpenProject : serveur MCP introduit en 17.2 (mars 2026) comme add-on Enterprise des offres Professional et supérieures, écriture sur les work packages ajoutée en 17.8 (septembre 2026)²⁶. Pas d'assignation à un agent.
• ClickUp : serveur MCP officiel (mcp.clickup.com/mcp), disponible sur tous les forfaits²⁷. ClickUp a racheté Codegen en décembre 2025 et permet d'assigner une tâche à un agent de code²⁸.
• Huly : le README du dépôt officiel indique depuis le 25 septembre 2026 que le dépôt est gelé, et l'offre hébergée a fermé ; jusqu'au 9 novembre 2026, il attribuait la fermeture à l'arrêt du financement de l'hébergement et renvoyait vers un fork communautaire, Platform-Collective²⁹. À écarter.
• Jira Cloud : l'Atlassian Rovo MCP Server est en disponibilité générale depuis le 4 février 2026, compatible notamment avec Claude, ChatGPT, Cursor et VS Code, Claude Code compris d'après la documentation de configuration³⁰. Il connecte les clients IA aux applications Atlassian Cloud : Jira Data Center n'y a pas accès³¹.

Comment situer votre maturité AI4IT ?

Aucun standard ne fait consensus. Nous partons de trois références publiées. Dan Shapiro, dans « The Five Levels: from Spicy Autocomplete to the Dark Factory » (23 janvier 2026), décrit six niveaux, de 0 à 5, de l'autocomplétion à l'usine logicielle sans humain dans la boucle³². Steve Yegge, dans « Welcome to Gas Town » (1er janvier 2026), compte huit étapes, d'un usage quasi nul de l'IA à l'écriture de son propre orchestrateur³³. Le DORA AI Capabilities Model de Google Cloud (23 septembre 2025) retient sept capacités qui amplifient l'effet de l'IA : une position claire sur l'IA, des écosystèmes de données sains, des données internes accessibles à l'IA, de solides pratiques de contrôle de version, le travail en petits lots, le focus utilisateur et des plateformes internes de qualité³⁴. Le billet de lancement précise que connecter les outils d'IA aux sources de données internes renforce leur effet sur l'efficacité individuelle et la qualité du code, ce qui est l'argument même du ticket dans le repo. Les paliers de maturité de Boris Cherny tracent une progression voisine.

L'échelle ci-dessous est une proposition SFEIR qui fait la synthèse. Les correspondances avec Shapiro et Yegge sont notre lecture, pas la leur.

Niveau SFEIR	Description	Correspondance Shapiro / Yegge
N0	Pas d'IA, ou usage ponctuel en chat	Shapiro 0 / Yegge 1
N1	Assistants et autocomplétion, agent en IDE validé pas à pas	Shapiro 1 / Yegge 2-3
N2	Agents de code supervisés en harnais (Claude Code, OpenCode, Codex CLI, Cursor)	Shapiro 2 / Yegge 4-5
N3	Agents en parallèle (worktrees), délégation de tickets, agents en CI	Shapiro 3 / Yegge 6-7
N4	Software factory : orchestrateurs, flottes d'agents, humain auteur de specs	Shapiro 4-5 / Yegge 8

Le principe qui guide la suite : plus le niveau monte, plus le ticket doit être lisible et modifiable par l'agent sans quitter son environnement de travail.

Quinze solutions notées sur huit critères agent

Chaque critère est noté de 0 à 5 :

• C1 : lecture directe dans le repo, sans API ;
• C2 : écriture et mise à jour par l'agent ;
• C3 : versionnement avec le code (même branche, même commit) ;
• C4 : CLI ou MCP officiel ;
• C5 : fonctionnement hors ligne et en worktrees ou sandboxes parallèles ;
• C6 : sobriété en contexte et en tokens ;
• C7 : assignation et délégation à des agents ;
• C8 : traçabilité et audit.

Le score agent est la moyenne de C1 à C8. L'accessibilité pour les non-développeurs (NB) est notée à part, parce que c'est là que se joue le vrai arbitrage. Notes établies sur les fonctionnalités documentées au 13 novembre 2026.

Solution	C1	C2	C3	C4	C5	C6	C7	C8	Score agent /5	NB
Backlog.md	5	5	5	5	4	5	3	4	4,5	3
Beads	3	5	4	5	5	5	4	4	4,4	1
Markdown dans le repo (convention + CLI maison)	5	4	5	3	5	5	3	4	4,3	2
Spec Kit / OpenSpec (complément)	5	5	5	4	4	4	2	4	4,1	2
Task Master	4	5	4	5	3	3	2	3	3,6	1
GitHub Issues + Projects	1	4	1	5	1	3	5	4	3,0	4
Linear	1	5	1	5	1	3	5	3	3,0	5
git-bug	2	3	2	3	5	4	1	4	3,0	2
GitLab Issues / Work Items	1	4	1	5	1	3	4	4	2,9	4
Plane	1	5	1	5	2	3	3	3	2,9	4
Jira Cloud + Rovo MCP	1	4	1	5	1	2	2	5	2,6	4
ClickUp	1	4	1	4	1	2	4	3	2,5	5
YouTrack	1	3	1	4	1	3	1	4	2,3	4
OpenProject	1	3	1	3	1	3	0	4	2,0	4
Jira Data Center	1	2	1	1	1	2	0	5	1,6	4

Beads perd des points en C1 parce que son stockage Dolt ne se lit pas comme du texte brut, et en gagne en C5 et C6 grâce à ses identifiants hachés et à sa compaction. Task Master obtient 3 en C6 : son mode par défaut charge 7 outils pour environ 5 000 tokens, mais le jeu complet en coûte quatre fois plus. GitHub et Linear obtiennent 5 en C7 grâce à une délégation native, et 1 en C1, C3 et C5 : l'issue vit dans une base distante, hors de la branche. GitLab monte à 5 en C4 avec un MCP en disponibilité générale et à 4 en C7, la délégation à un agent externe restant réservée aux offres Premium et Ultimate et soumise à un feature flag. Jira Cloud obtient 5 en audit et en MCP, mais 2 en sobriété : schémas verbeux, champs personnalisés, appels réseau. Jira Data Center cumule l'absence de MCP officiel et une fin de vie programmée.

Quel outil choisir selon votre niveau ?

Maturité	Recommandé	Acceptable	À éviter
N0	GitLab ou GitHub Issues, Plane	Linear, YouTrack, OpenProject, Jira Cloud	Nouveau Jira Data Center, Huly
N1	GitLab ou GitHub Issues avec MCP, Linear	Plane, Jira Cloud + Rovo MCP, YouTrack	Jira Data Center, Task Master
N2	Backlog.md ou Markdown dans le repo, plus le tracker de la forge pour le métier	Linear, GitHub ou GitLab avec MCP, Spec Kit ou OpenSpec	Jira Data Center, OpenProject sans add-on MCP
N3	Markdown dans le repo (Backlog.md) + Spec Kit ou OpenSpec, board synchronisé	Beads ; Linear, GitHub ou GitLab avec délégation d'agents	Tout tracker sans MCP ni délégation
N4	Beads ou Markdown + CLI typée, orchestrateur, board en projection	Backlog.md, Linear en vue métier synchronisée	Tout outil qui impose un aller-retour API pour lire un ticket

Où le tout-Markdown casse-t-il ?

• Le reporting de portefeuille (vélocité multi-équipes, capacité, roadmap trimestrielle) n'existe pas nativement. Il faut une projection, comme le board de Golverdingen, ou un tracker en aval.
• Le multi-repo demande un agrégateur. Beads a pris le problème en charge : on importe le dépôt voisin dans sa base (bd repo add, puis bd repo sync) ou on dépend d'une capacité d'un autre projet³⁵. Une convention tickets/ maison doit construire cet agrégateur elle-même.
• Les permissions suivent celles du repo : impossible de masquer un ticket sensible à un contributeur qui a accès au code.
• La conformité (ITSM, SOX, demandes clients) reste mieux servie par un outil dédié avec un workflow opposable, même si l'historique git fournit une piste d'audit solide.
• Les non-développeurs ne doivent jamais éditer de YAML. Il leur faut une interface ou un MCP, et quelqu'un doit les construire.
• La qualité des données se dégrade sans CLI typée ni validation en CI. On retombe alors dans les 605 plans à l'abandon de Yegge.
• La jeunesse des outils : beaucoup reposent sur un seul mainteneur. Yegge a lui-même documenté la fragilité de Beads à l'automne 2025, la dernière version de Task Master date de mars 2026, et Huly montre qu'un projet peut s'arrêter.
• L'échelle : le retour de Warmtebouw concerne une équipe de douze personnes. Il ne prouve pas que le modèle tienne sur des centaines de développeurs sans outillage d'agrégation.

Comment migrer depuis Jira, étape par étape

1. Auditer avant de migrer. Exporter Jira (CSV, XML ou API REST), recenser les champs personnalisés et les workflows réellement utilisés, supprimer les champs morts, faire correspondre epic, story, sous-tâche et statut au modèle cible.
2. Lancer un pilote sur une équipe de niveau N2 ou plus. Une équipe, un repo, Backlog.md ou une convention tickets/ à frontmatter validé en CI. Les écritures passent uniquement par la CLI ou le MCP. Le fichier AGENTS.md ou CLAUDE.md impose aux agents de lire le ticket et de le mettre à jour dans le même commit que le code.
3. Passer au modèle hybride. Le Markdown du repo fait foi pour les agents ; une synchronisation à sens unique alimente un board (issues de la forge, Plane ou Linear) pour le métier. Le sens inverse, board maître et repo esclave, recrée le problème de départ. Les non-développeurs écrivent donc dans le repo par le MCP ou par une interface branchée sur la CLI, comme chez Warmtebouw ; le board aval ne sert qu'à lire.
4. Mettre Jira en lecture seule pendant une à deux périodes de reporting, puis l'archiver.
5. Monter en maturité. Quand les agents tournent en parallèle, adopter des identifiants anti-collision sur le modèle de Beads et des specs versionnées avec Spec Kit ou OpenSpec.

Ce que ça change pour vous

• DSI : la fin de vie de Data Center impose une migration avant mars 2029. Choisir Jira Cloud par défaut revient à payer une migration pour garder un modèle que vos agents contournent. Décidez d'abord où vit le backlog d'ingénierie, ensuite quel board sert le portefeuille.
• CTO, lead dev, architecte : avec Backlog.md, le pilote se monte en une semaine sur un repo. Une convention maison coûte davantage : Warmtebouw a dû écrire sa CLI typée, sa validation en CI, son board et un serveur MCP de 20 outils avant d'atteindre une heure de maintenance par semaine.
• RSSI, conformité : un backlog dans le repo hérite des droits du repo. Gardez les tickets sensibles (incidents de sécurité, demandes clients nominatives) dans un outil à permissions fines, et privilégiez un MCP qui parle à votre instance, comme celui de GitLab, plutôt qu'un SaaS tiers.
• Achats : la hausse Cloud d'octobre 2026 tourne autour de 7 % sur les petites tranches, et la facturation à l'usage de Rovo s'ajoute à partir de décembre. Les outils dans le repo sont pour la plupart open source ; leur coût est l'outillage interne, pas la licence.

Notre recommandation pour une organisation sur GitLab privé

Pour une organisation de niveau N2 ou plus, ne migrez pas de Jira vers un autre Jira. Mettez le backlog d'ingénierie dans le repo, en Markdown structuré, écrit par des outils et jamais à la main, et réservez un board synchronisé au métier et au portefeuille. Sur une instance GitLab privée, comme celle de SFEIR, le choix concret est le suivant : Backlog.md ou une convention tickets/ maison dans chaque repo, OpenSpec ou Spec Kit pour les changements importants, et le serveur MCP de GitLab (outils work items) pour exposer une vue métier sans faire sortir les données de l'instance. Jira Cloud se justifie là où le portefeuille, le support client ou la conformité l'exigent. Jira Data Center s'arrête en mars 2029.

Sources

1. Atlassian, « Data Center End of Life » (dates de fin de vie, de fin de vente et d'extension, Bitbucket et Bamboo), consulté le 13 novembre 2026. atlassian.com
2. Atlassian, « Ascend to the cloud: The next chapter for Atlassian and our customers », septembre 2025, pièce 99.1 déposée auprès de la SEC. sec.gov
3. Atlassian, « Future pricing: Cloud » et grilles tarifaires (Jira Standard et Premium, tranche 1-100), consultées le 13 novembre 2026. atlassian.com
4. Tamar Yehoshua, « Atlassian's usage-based pricing: AI value with predictability and control », Atlassian, 1er septembre 2026 ; page « Usage-based pricing » consultée le 13 novembre 2026. atlassian.com
5. David Golverdingen, « We Replaced Jira With Markdown Files », 11 août 2026, mis à jour le 22 octobre 2026. davidgolverdingen.nl
6. Alex Gavrilescu, dépôt Backlog.md (README et CLI-INSTRUCTIONS.md), GitHub, consulté le 13 novembre 2026. github.com
7. Alex Gavrilescu, « A year of building Backlog.md: do we still need a task manager in the AI era? », 7 juillet 2026. mrlesk.com
8. Steve Yegge et contributeurs, dépôt Beads (README et CHANGELOG, versions 0.56.0 et 0.58.0), GitHub, consulté le 13 novembre 2026. github.com
9. Steve Yegge, « Introducing Beads: A coding agent memory system », Medium, 13 octobre 2025. medium.com
10. Steve Yegge, « Beads Blows Up », Medium, 6 novembre 2025. medium.com
11. Dépôt Gas Town (section « Beads Integration »), GitHub, consulté le 13 novembre 2026. github.com
12. Eyal Toledano, dépôt claude-task-master (README, docs/configuration.md, mcp-server/src/tools/index.js), GitHub, consulté le 13 novembre 2026. github.com
13. Dépôt git-bug (README, notes de version v0.11.0 et v0.12.0), GitHub, consulté le 13 novembre 2026. github.com
14. GitHub, dépôt Spec Kit, consulté le 13 novembre 2026. github.com
15. Fission AI, dépôt OpenSpec (README et docs/concepts.md), GitHub, consulté le 13 novembre 2026. github.com
16. GitHub Docs, « Using Copilot in the cloud on GitHub », consulté le 13 novembre 2026. docs.github.com
17. Linear, « Linear MCP server », changelog, 1er mai 2025. linear.app
18. Linear, documentation « MCP » et guide « AI agents », consultés le 13 novembre 2026. linear.app
19. Linear, changelog du 13 août 2026 (accès MCP géré par Okta). linear.app
20. GitLab Docs, « GitLab MCP server », consulté le 13 novembre 2026. docs.gitlab.com
21. GitLab, « GitLab 19.4 release notes ». docs.gitlab.com
22. GitLab Docs, « External agents » (Duo Agent Platform), consulté le 13 novembre 2026. docs.gitlab.com
23. Plane, documentation « MCP server », consultée le 13 novembre 2026. developers.plane.so
24. Plane, « Introducing MCP Connectors and Cursor agent », 15 mai 2026. plane.so
25. JetBrains, documentation YouTrack « Model Context Protocol server » (Cloud 2026.2) et « MCP Tools » (portail développeur), consultées le 13 novembre 2026. jetbrains.com
26. OpenProject, « OpenProject 17.8 », 2 septembre 2026. openproject.org
27. ClickUp, « Connect an AI assistant to ClickUp's MCP server », documentation développeur, consultée le 13 novembre 2026. developer.clickup.com
28. ClickUp, annonce du rachat de Codegen, 22 décembre 2025. clickup.com
29. Huly, dépôt hcengineering/platform (README et historique des commits du 25 septembre et du 9 novembre 2026), GitHub. github.com
30. Atlassian, « Atlassian Rovo MCP Server is now GA », 4 février 2026. atlassian.com
31. Atlassian Developer, « Rovo MCP Server », consulté le 13 novembre 2026. developer.atlassian.com
32. Dan Shapiro, « The Five Levels: from Spicy Autocomplete to the Dark Factory », 23 janvier 2026. danshapiro.com
33. Steve Yegge, « Welcome to Gas Town », Medium, 1er janvier 2026. medium.com
34. Kevin M. Storer et Derek DeBellis, « Introducing DORA's inaugural AI Capabilities Model », Google Cloud Blog, 23 septembre 2025. cloud.google.com
35. Beads, FAQ (docs/reference/faq.md), GitHub, consultée le 13 novembre 2026. github.com