Atlassian a fixé la date : le 28 mars 2029, les produits Data Center cessent d’exister. Jira Software, Jira Service Management, Confluence et Crowd passeront en lecture seule, sans mises à jour ni correctifs de sécurité. C’est la fin de Jira en auto-hébergement : l’arrêt des versions Server, en février 2024, ne laissait que Data Center ; après mars 2029, il ne restera que le Cloud d’Atlassian.
Pour beaucoup de DSI, ce n’est pas une montée de version, c’est un changement de modèle : les données quittent vos serveurs. Si vous aviez choisi l’auto-hébergement pour de bonnes raisons — réglementaires, contractuelles ou politiques — le calendrier d’Atlassian vous oblige à rouvrir le dossier. GLPI est l’une des réponses possibles : logiciel libre, éditeur français, hébergé là où vous le décidez.
Reste la question qui bloque la plupart des projets : comment passe-t-on de l’un à l’autre sans perdre son historique ni interrompre son support pendant trois semaines ? C’est précisément pour y répondre que nous avons développé notre propre outil de reprise des données de Jira vers GLPI. Voici le calendrier, la méthode et les pièges que nous rencontrons le plus souvent.
Le calendrier d’Atlassian, dans le détail
Trois dates structurent la décision, et la première est déjà derrière nous :
- 30 mars 2026 — passé. Un nouveau client ne peut plus acheter Data Center. Si votre organisation n’est pas déjà équipée, la question ne se pose même plus : l’auto-hébergement chez Atlassian n’est plus une option commerciale.
- 30 mars 2028. Les clients existants ne peuvent plus souscrire de nouveaux abonnements ni étendre les leurs. Votre licence cesse donc de pouvoir grandir avec vos équipes près d’un an avant l’échéance finale.
- 28 mars 2029. Fin de vie. Les abonnements expirent et l’instance passe en lecture seule : plus de support, plus de mises à jour, plus de correctifs de sécurité. Atlassian recommande d’ailleurs de ne pas laisser une instance en lecture seule connectée à Internet.
Une maintenance étendue reste possible, mais à un coût supplémentaire et « par exception ». Ce n’est pas un plan : c’est une porte de sortie négociée au cas par cas, et elle ne se pilote pas depuis un budget prévisionnel.
Deux points n’ont pas changé par ailleurs. Jira Service Management se facture au nombre d’agents : chaque technicien supplémentaire augmente la facture annuelle, et l’addition grimpe vite dès que le support s’élargit au-delà de l’équipe informatique. Et l’inventaire du parc reste un module payant supplémentaire, quand il est natif dans GLPI.
GLPI, lui, est un logiciel libre : son cœur ne comporte pas de licence par utilisateur. Les souscriptions proposées par l’éditeur couvrent le support, les plugins et les mises à jour, pas le droit d’usage. Le modèle de coût n’évolue donc pas de la même façon quand l’équipe grandit — et surtout, aucune date d’expiration ne pèse sur votre installation.
La souveraineté, posée franchement
Atlassian a achevé son transfert de siège social vers les États-Unis en septembre 2022 : la maison mère, Atlassian Corporation, est aujourd’hui une société de droit américain, immatriculée dans le Delaware et cotée au Nasdaq. Ce n’est pas un procès d’intention, c’est un fait juridique, et il a une conséquence concrète : une entreprise de droit américain peut se voir enjoindre par les autorités de son pays de produire les données qu’elle détient, y compris lorsqu’elles sont stockées en Europe.
Tant que votre Jira tournait sur vos propres serveurs, la question ne se posait pas : vous déteniez la base. Après mars 2029, elle se pose, parce que la seule voie supportée par l’éditeur est son Cloud. Autrement dit, la fin de Data Center ne vous demande pas seulement de changer de version : elle vous demande de confier à un prestataire américain des données que vous aviez délibérément gardées chez vous.
GLPI répond autrement. C’est un logiciel libre : vous détenez le code et la base, et personne ne peut vous retirer le droit de les utiliser. Il est édité par Teclib’, une entreprise française, qui en est l’éditeur depuis 2015. Et il s’héberge là où vous le décidez : vos serveurs, votre datacenter, ou un hébergeur français. Aucun calendrier d’éditeur ne peut vous contraindre à déplacer vos données.
Pour un hôpital, une collectivité, un opérateur d’importance vitale ou un industriel sous contrat de défense, ce n’est pas un argument de plaquette : c’est souvent une contrainte écrite, dans un marché ou dans une politique de sécurité des systèmes d’information. Et ce qui vaut pour l’hébergement vaut pour l’outil qui gère le parc et les tickets, parce qu’il contient la cartographie complète de votre système d’information.
Ce que vous gagnez, ce que vous perdez
Autant le dire franchement : une migration n’a de sens que si le nouvel outil couvre vos usages réels. GLPI est fort là où Jira Service Management l’est moins, et l’inverse est vrai aussi.
Ce que GLPI apporte en plus :
- Un inventaire natif du parc, alimenté automatiquement par des agents installés sur les postes et serveurs.
- La gestion des contrats, des licences et des coûts rattachée directement aux équipements.
- Un coût qui ne suit pas le nombre de techniciens.
- Un hébergement que vous choisissez, et qu’aucune échéance d’éditeur ne remet en cause.
Ce que vous quittez :
- L’intégration étroite avec Jira Software et Confluence, si vos équipes de développement travaillent dessus. C’est souvent le point bloquant : un lien ticket ↔ développement perdu coûte plus cher qu’une licence.
- Un écosystème d’applications Marketplace plus large que celui des plugins GLPI.
- Des automatisations déjà en place, qu’il faudra réécrire.
Si vos développeurs vivent dans Jira Software, la bonne réponse est rarement de tout migrer : elle consiste plutôt à sortir la gestion de parc et le helpdesk vers GLPI, et à conserver Jira pour le développement.
Le marché ne propose aucun outil de migration. Nous avons développé le nôtre.
C’est le point qui bloque la plupart des projets : il n’existe, sur le marché, aucun outil qui transfère un Jira Service Management vers un GLPI. Les deux modèles de données sont trop éloignés. Ce que Jira appelle un projet, un type de demande ou un champ personnalisé n’a pas d’équivalent direct dans l’arborescence des entités, des catégories et des gabarits de GLPI. Résultat : chaque migration se refait de zéro, à coups de scripts jetables, et le budget part dans la plomberie plutôt que dans le paramétrage.
Nous avons pris le problème à l’envers. Plutôt que de réécrire ces scripts à chaque projet, nous avons développé un outil de reprise des données Jira vers GLPI que nous faisons évoluer d’une migration à l’autre. Le temps qui n’est plus dépensé à construire la plomberie se reporte sur ce qui compte vraiment : les entités, les catégories, les SLA et les règles métier.
Ce qu’il est possible de reprendre dépend de votre installation : de la version de Jira que vous utilisez, de la façon dont vos projets et vos champs personnalisés ont été construits, et de ce que vous devez pouvoir retrouver demain. Il n’y a pas de réponse générale à cette question, et nous nous méfions de ceux qui en donnent une. Si le sujet est sur votre table, écrivez-nous : nous regardons votre cas et nous vous disons ce qui est réaliste.
Un point reste vrai malgré l’outil, et il faut l’entendre : une migration ne se décide pas, elle se construit. On choisit ce qu’on reprend, sous quelle forme, et ce qu’on laisse derrière. C’est une bonne nouvelle déguisée : une reprise à l’identique reproduirait dans le nouvel outil les défauts de paramétrage accumulés dans l’ancien.
Les cinq chantiers, dans l’ordre
1. Le référentiel des actifs
On commence toujours par là. Les tickets se rattachent à des équipements, à des utilisateurs et à des entités : si ces objets n’existent pas encore dans GLPI, les tickets repris arrivent orphelins. L’inventaire natif de GLPI fait l’essentiel du travail en découvrant le parc automatiquement ; la reprise ne sert qu’à ce que l’agent ne voit pas (mobiles, équipements réseau, contrats).
2. Les utilisateurs et les entités
Le plus simple est de brancher GLPI sur votre annuaire (LDAP ou Active Directory) plutôt que d’importer une liste figée. L’occasion de poser proprement l’arborescence des entités, qui est la notion structurante de GLPI : elle détermine qui voit quoi, et se change difficilement après coup.
3. Le catalogue de services et les formulaires
Chaque type de demande Jira devient, côté GLPI, une combinaison de catégorie de ticket, de gabarit et de formulaire. Les formulaires natifs de GLPI 11 couvrent aujourd’hui les demandes guidées (arrivée d’un collaborateur, demande d’accès, commande de matériel) qui nécessitaient auparavant un plugin.
4. Les tickets et leur historique
Le chantier que notre outil prend en charge, détaillé juste en dessous.
5. Les SLA et les automatisations
GLPI gère les délais via ses SLA et ses règles métier. Ces règles ne se transposent pas : elles se réécrivent. Prévoyez de les tester sur des tickets réels avant la bascule, car une règle d’affectation mal ordonnée se voit tout de suite au support.
Reprendre l’historique : trois options
Il n’y a pas de bonne réponse unique. Le choix dépend de ce que vous devez pouvoir prouver, et pendant combien de temps.
Option 1 — La reprise par notre outil
C’est la voie que nous proposons par défaut, et la seule qui permette de reprendre un historique long sans y consacrer des semaines de développement spécifique. Le périmètre exact se définit avec vous, en fonction de votre installation et de ce que vous devez conserver.
Option 2 — Export CSV et injection
Jira exporte ses demandes en CSV, et le plugin Data Injection de GLPI sait les relire. C’est une voie légère, suffisante quand on ne veut récupérer que les champs structurants de quelques centaines de tickets récents. Sa limite est connue : les échanges longs et les pièces jointes passent mal.
Option 3 — Repartir propre, archiver l’ancien
L’option la plus sous-estimée : on ne reprend que les tickets ouverts, et l’ancien outil est conservé en lecture seule le temps de la durée de conservation que vous vous imposez. Dans la plupart des helpdesks, un ticket clos depuis plus d’un an n’est jamais rouvert. Cette option divise le budget de migration par deux ou trois, et nous la recommandons sans hésiter quand rien ne vous oblige à conserver le détail.
Quelle que soit l’option retenue, la règle ne change pas : on teste sur un échantillon de cinquante à cent tickets, sur une copie de la base, avant de lancer la reprise complète.
Les pièges les plus fréquents
- Les champs personnalisés sans équivalent. Chaque champ Jira doit trouver une destination : champ natif, champ additionnel, ou poubelle. Arbitrer cela après la reprise coûte dix fois plus cher qu’avant.
- Les dates. Un ticket repris doit conserver sa date d’ouverture d’origine, sinon vos indicateurs de délai sont faux dès le premier jour.
- Les auteurs disparus. Les tickets d’anciens salariés se rattachent à des comptes qui n’existent plus dans l’annuaire. Prévoyez un utilisateur technique de reprise plutôt que de laisser le champ vide.
- Les notifications. À la première reprise massive, GLPI prévient tout le monde. Coupez les notifications pendant l’opération, c’est la mésaventure classique.
- L’arborescence des entités décidée trop tard. Elle conditionne la visibilité de toutes les données reprises. On la pose avant, pas pendant.
Combien de temps faut-il prévoir ?
Pour un helpdesk d’une dizaine de techniciens et un parc de quelques centaines d’équipements, nous comptons généralement :
- Un à deux jours d’audit pour cartographier l’existant et décider du périmètre repris.
- Quelques jours d’installation et de paramétrage : entités, annuaire, catégories, gabarits, SLA, règles.
- Le chantier de reprise, nettement raccourci par notre outil : l’essentiel du temps passe désormais dans les arbitrages, plus dans le développement.
- Une période de double usage de deux à quatre semaines : les nouveaux tickets s’ouvrent dans GLPI, les anciens se terminent dans Jira. C’est la façon la plus sûre de ne bloquer personne.
- La formation des techniciens et des utilisateurs, à ne pas traiter en fin de projet : un outil bien paramétré mais mal adopté produit un helpdesk fantôme.
Faut-il migrer ?
La vraie question n’est plus « faut-il migrer ? » mais « vers quoi, et quand ? ». Quitter Data Center n’est pas un choix : la date est fixée. Le choix porte sur la destination — le Cloud d’Atlassian, ou un outil que vous hébergez.
Et migrer vers GLPI n’est pas toujours la bonne réponse, nous le disons quand c’est le cas. Si vos équipes de développement travaillent dans Jira Software et que le lien entre les tickets de support et les développements est utilisé au quotidien, la migration complète vous fera perdre plus qu’elle ne vous fera gagner. Si en revanche votre ITSM sert à gérer un parc, des contrats et un helpdesk, et que la facture suit la taille de votre équipe, GLPI mérite une comparaison chiffrée.
Le bon point de départ est un audit du périmètre réellement utilisé dans Jira. Dans la moitié des cas, il révèle qu’une partie des fonctionnalités payées ne sert plus. Et il vaut mieux le mener maintenant qu’en 2028 : à cette date, votre licence ne pourra plus être étendue, et le calendrier choisira à votre place. Et si la décision est prise, la reprise de vos données n’est plus le point bloquant : c’est devenu notre métier. Parlons de votre situation.
Pour aller plus loin : notre guide complet de GLPI, l’installation pas à pas, la gestion des tickets et les plugins indispensables.
