Fin du support d'Atlassian Connect au 31 janvier 2027 : migrer vos applications Jira et Confluence sur mesure vers Forge

Le 31 janvier 2027, Atlassian met fin au support de Connect, le framework sur lequel ont été construites la plupart des anciennes applications Jira et Confluence Cloud. À partir de ce jour, Atlassian indique qu'elle « ne traitera plus que les vulnérabilités de sécurité critiques dans Connect », et qu'une application privée qui tourne encore sur Connect « ne sera plus supportée et risque de ne plus fonctionner correctement ».

Si toutes les applications de votre site viennent de l'Atlassian Marketplace, c'est l'affaire de vos éditeurs, et la plupart l'ont fait : Atlassian indiquait en août 2026 que « plus de 95 % des sièges d'applications payantes ont été migrés vers Forge ».

Cet article traite de l'autre cas. Votre entreprise a une application Jira ou Confluence que quelqu'un a construite pour vous : un développeur interne, un prestataire, un partenaire. Elle a été installée par un lien, pas achetée. Personne en dehors de votre entreprise ne va la migrer, et celui qui l'a écrite n'est peut-être plus là.

Ce que signifie la fin du support, et ce qu'elle ne signifie pas

Il n'y a pas de date d'arrêt publiée. Atlassian n'a pas dit que les applications Connect cesseront de tourner le 1er février 2027, et son annonce initiale du calendrier précisait que « les clients qui ont des applications Connect installées ne perdront pas l'accès à l'application ».

N'y voyez pas une garantie. Ce qui change, c'est que plus personne chez Atlassian ne s'occupe de Connect :

• Seules les vulnérabilités de sécurité critiques sont corrigées. Les bogues non critiques restent.
• « Les dépréciations de fonctionnalités de Connect interviendront avec peu de préavis. »
• Le support d'Atlassian « ne pourra pas corriger les problèmes causés par cette technologie héritée ».
• Selon les termes d'Atlassian elle-même : « Connect ne restera pas dans un état stable après la fin du support. Les dysfonctionnements vont se multiplier et les écarts de compatibilité se creuser. »

Le risque est donc progressif, pas une falaise. Une panne plausible : Jira modifie une page, un panneau Connect cesse de s'afficher, et il n'y a personne à qui ouvrir un ticket. Si cette application est au cœur d'une validation financière ou d'un service desk tourné vers les clients, vous l'apprendrez par ceux qui en dépendent.

Ce qui s'est déjà passé

La date de janvier est la dernière étape d'une séquence commencée en 2025.

• Septembre 2025 : la Marketplace a cessé d'accepter de nouvelles applications Connect.
• 31 mars 2026 : les mises à jour ont été gelées. Les recommandations d'Atlassian pour les applications sur mesure le disaient clairement : après cette date, « vous ne pourrez plus publier de mises à jour pour les applications Connect ». Le code sur votre propre serveur reste modifiable, mais ce que l'application déclare à Jira ou Confluence (ses modules, ses scopes et ses webhooks) est figé.
• Mars 2026 : le calendrier précisait aussi que « la possibilité d'installer de nouvelles applications Connect privées via Connected Apps ne sera plus disponible ». Considérez une désinstallation comme définitive : ne retirez pas une application Connect privée simplement pour voir ce qui casse.
• Août 2026 : Atlassian a repoussé la fin du support de décembre 2026 au 31 janvier 2027. C'est un mois de plus. Ne comptez pas sur un autre.
• Maintenant : Atlassian déploie des avertissements dans Atlassian Administration, où les applications privées encore sur Connect sont « signalées avec le statut LEGACY ».

Trouver vos applications privées

Commencez dans Atlassian Administration, sur la page Connected Apps. Tout ce qui porte l'étiquette LEGACY tourne sur Connect. La liste de contrôle d'Atlassian pour repérer une application privée : si la plupart de ces critères sont remplis, c'est à vous de la migrer :

• installée par un lien direct ou en mode développeur, pas depuis la Marketplace ;
• absente des résultats de recherche de la Marketplace ;
• votre organisation maintient le code source ;
• aucune information de licence, et votre organisation est la seule listée dans les installations ;
• pas de barre latérale de liens associés sur sa page Connected Apps (les applications de la Marketplace en ont une).

Atlassian ajoute une règle empirique : une application cloud sur mesure construite il y a plus de cinq ans est probablement une application Connect, et les applications Connect sont hébergées hors d'Atlassian, « généralement sur un service comme Heroku, AWS, Azure ou Google Cloud Platform ». Le lien View app details de l'application indique qui en est le développeur, pour autant qu'Atlassian le sache.

Pour chaque application, notez cinq choses avant que quiconque ne touche au code :

1. Ce qu'elle fait et qui l'utilise, en une phrase qu'un responsable métier reconnaîtrait.
2. Où se trouve le code source. Un dépôt que vous contrôlez, l'ordinateur portable d'un prestataire, ou nulle part.
3. Où elle tourne, et quel compte paie l'hébergement. Si le serveur est sur le compte cloud d'un ancien prestataire, c'est un risque dès aujourd'hui, pas en janvier.
4. Le descripteur. Chaque application Connect sert un fichier atlassian-connect.json à une URL. Il recense chaque module, scope et webhook qu'utilise l'application, ce qui en fait l'inventaire le plus fiable que vous obtiendrez.
5. Les données qu'elle conserve, et où : dans sa propre base de données, ou dans des propriétés stockées sur les tickets Jira et les pages Confluence.

Décider avant de construire

Toutes les applications privées ne méritent pas une migration. Le conseil d'Atlassian elle-même est de vérifier si une fonctionnalité native de Jira ou de Confluence fait désormais le travail, et de ne migrer que ce dont l'organisation a encore besoin. Les anciennes applications comblaient souvent un manque que le produit a depuis comblé lui-même.

Chaque application reçoit l'une de trois réponses : migrer, remplacer par une solution supportée, ou retirer. Retirer est une issue légitime. Atlassian recommande, si vous abandonnez une application, d'en informer ses utilisateurs et de programmer son retrait avant le 31 janvier 2027, plutôt que de la laisser tomber en panne d'elle-même.

Ce qu'implique le passage à Forge

Forge n'est pas Connect sous un nouveau nom. Le modèle d'hébergement, le modèle de sécurité et le modèle d'interface diffèrent tous, et c'est pourquoi Atlassian conseille même aux propriétaires d'applications simples de lancer tôt une preuve de concept.

L'hébergement

Une application Connect est un service web que vous exploitez. Une application Forge tourne sur l'infrastructure d'Atlassian sous forme de fonctions soumises à des limites strictes : 25 secondes pour une fonction déclenchée par un utilisateur, jusqu'à 900 secondes pour les événements asynchrones et les déclencheurs planifiés. Une application Connect qui exécute une synchronisation de dix minutes pendant que l'utilisateur attend doit déplacer ce travail dans des événements asynchrones, et tout ce qui dépasse quinze minutes doit être découpé en étapes. Les appels sortants sont restreints eux aussi : tout domaine non déclaré dans le manifeste de l'application est rejeté.

Garder le backend que vous avez

Forge Remote permet à une application Forge d'appeler des services que vous hébergez ailleurs, permet à votre serveur de vérifier qu'une requête vient bien de Forge, et fournit à votre backend des jetons pour appeler les API d'Atlassian. Pour une application privée qui porte des années de logique métier sur son serveur, c'est souvent la voie la plus courte : l'interface et les points d'intégration passent sur Forge, la logique reste où elle est.

La contrepartie : Forge Remote peut rendre une application inéligible au programme Runs on Atlassian. Pour un outil interne, cela compte moins, mais votre équipe sécurité doit l'accepter en connaissance de cause.

Authentification et autorisations

Les applications Connect s'authentifient par un JWT signé avec un secret partagé. Forge remplace cela par des scopes OAuth 2.0 déclarés dans le manifeste et, pour les backends distants, par un Forge Invocation Token que votre serveur valide à la place d'un JWT.

Chaque appel authentifié à l'API Jira ou Confluence se fait alors soit asUser, avec les autorisations de la personne qui utilise l'application, soit asApp, qui, selon les termes d'Atlassian, fonctionne « quel que soit l'utilisateur de l'application ». Passer en revue chaque appel et choisir délibérément constitue la revue de sécurité la plus importante de toute la migration.

Une différence prend les équipes au dépourvu. Les modules Connect s'affichent par défaut pour les utilisateurs sans licence et anonymes ; les modules Forge, non, sauf si le manifeste l'autorise avec unlicensedAccess. Si votre application montre quoi que ce soit aux clients du service desk ou aux lecteurs anonymes de Confluence, testez ce chemin à part.

L'interface utilisateur

Les pages Connect sont des iframes qui dialoguent avec Jira ou Confluence par l'API JavaScript d'Atlassian. Forge vous offre deux options :

• UI Kit : un framework basé sur React qui affiche des composants Atlassian natifs. Rapide et cohérent, mais vous construisez à partir des composants d'Atlassian : du HTML personnalisé peut ne pas fonctionner, et les seules ressources statiques acceptées sont des images.
• Custom UI : votre propre HTML, CSS et JavaScript dans une iframe, qui dialogue avec le produit via @forge/bridge.

Une interface existante en iframe passe généralement sur Custom UI avec le moins de modifications. Les petits panneaux et les écrans de paramètres sont souvent plus rapides à refaire en UI Kit.

Les données

C'est là que les migrations tournent mal. Forge dispose de son propre stockage hébergé : un magasin clé-valeur, un magasin d'entités personnalisées, Forge SQL, et un magasin d'objets en préversion. Les données sont cloisonnées par installation et conservées au même endroit que le site Jira ou Confluence hôte : la résidence des données vient donc sans configuration supplémentaire.

Ce que cela signifie pour une application privée :

• Les données de la propre base de l'application Connect sont soit transférées dans le stockage Forge par une tâche de migration ponctuelle, soit laissées en place et atteintes via Forge Remote.
• Tout ce que l'application Connect a stocké côté Atlassian sous sa propre clé d'application doit être exporté tant que l'ancienne application tourne encore. Testez tôt si la nouvelle application peut le lire ; ne le supposez pas.
• Forge conserve les données hébergées pendant 28 jours après une désinstallation, mais une réinstallation ne les restaure pas automatiquement.

Écrivez la migration sous forme de script rejouable, avec des décomptes vérifiables, répétez-la sur un site de test, et gardez l'export.

La voie progressive, et pourquoi ce n'est probablement pas la vôtre

Atlassian a prévu une voie plus douce pour les applications Connect : adopter Forge progressivement, conserver les installations existantes, convertir le descripteur en manifeste Forge et migrer une famille de modules à la fois, avec une migration des données intégrée pour certains modules comme les macros, les champs personnalisés et les validateurs de workflow.

Le hic se trouve dans le premier paragraphe du guide : « L'adoption progressive de Forge n'est disponible que pour les applications Connect Confluence et Jira déjà publiées sur la Marketplace. »

Pour une application privée, prévoyez une nouvelle application Forge. Vous la déployez dans l'environnement de production, la partagez avec votre site par un lien d'installation depuis la console développeur, la faites tourner à côté de l'ancienne application Connect pendant que les données sont migrées et que les utilisateurs testent, puis retirez l'application Connect.

Les guides d'adoption restent utiles pour leur correspondance entre modules, tout comme la liste des fonctionnalités Connect non disponibles dans Forge : plusieurs modules de Jira Service Management et la prise en charge de l'application mobile y sont marqués comme non prévus, et jiraReports est toujours à l'étude. Confrontez votre descripteur à cette liste dès la première semaine. Un manque à cet endroit change la conception.

Un plan à rebours depuis le 31 janvier 2027

Début octobre 2026, il reste environ dix-sept semaines, et décembre est court pour tout le monde. Un plan qui tient :

1. Cette semaine : recensez chaque application LEGACY avec les cinq informations ci-dessus. Vérifiez qui contrôle le code source et le compte d'hébergement.
2. D'ici la mi-octobre : décidez pour chaque application entre migrer, remplacer ou retirer. Prévenez les utilisateurs de tout ce qui sera retiré.
3. D'ici fin octobre : une preuve de concept Forge pour la partie la plus difficile de l'application la plus difficile. En général, c'est un module sans équivalent Forge direct, ou celui qui détient le plus de données.
4. Novembre : développement, et plusieurs exécutions de la migration des données sur un site de test.
5. Début décembre : installez l'application Forge à côté de l'application Connect, migrez une copie des données, et laissez ceux qui l'utilisent tous les jours la vérifier.
6. Janvier 2027 : migration finale, bascule des utilisateurs, et retrait de l'application Connect seulement après que la nouvelle a tourné proprement pendant un certain temps.

Un panneau unique qui lit des données Jira et ne stocke rien est un petit chantier. Une application avec sa propre base de données, ses règles de workflow et ses liens vers d'autres systèmes a besoin de chacune de ces semaines.

Si vous manquez la date, rien de ce qu'Atlassian a publié ne dit que l'application s'arrête ce jour-là. Mais vous faites alors tourner un processus métier sur une plateforme que son propriétaire a cessé de réparer. Considérez ce temps comme emprunté, et terminez la migration.

Quand le développeur d'origine est parti

Atlassian traite directement ce cas. Si vous ne parvenez pas à identifier ou à joindre le propriétaire d'origine de l'application, ou si vous n'avez plus la capacité de développement nécessaire, elle suggère de faire appel à un Solution Partner. Elle est tout aussi claire sur le fait que, sans le code source, « il peut être nécessaire de reconstruire l'application sur Forge à partir de zéro ».

Même sans code source, vous ne partez pas à l'aveugle. Le descripteur recense tout ce à quoi l'application se raccorde, son comportement peut être observé sur un site de test, et si votre entreprise paie le serveur, vous pouvez voir ce qui y est réellement déployé. Une reconstruction à partir de ces éléments est plus lente qu'un portage, mais c'est une quantité connue.

Où trouver de l'aide

Nous reprenons du code que personne dans l'équipe actuelle n'a écrit, comprenons ce qu'il fait réellement, et le migrons : pour une application Connect, cela signifie lire le descripteur et le serveur, construire l'application Forge, puis écrire et répéter la migration des données. Notre travail de maintenance de systèmes anciens est généralement le point de départ, et si vous avez des développeurs mais pas assez, le renforcement d'équipe ajoute des personnes à votre équipe le temps nécessaire. Dites-nous ce que fait l'application et où elle tourne : écrivez à office@c9group.dev.