Linear s'impose là où Jira fatigue : ce que ça dit de nos choix d'infrastructure

Linear s'impose là où Jira fatigue : ce que ça dit de nos choix d'infrastructure

Il y a quelque chose de symptomatique dans la manière dont les équipes tech parlent de Jira. Rarement avec enthousiasme, souvent avec résignation, parfois avec une hostilité à peine voilée. Linear, lui, génère un autre type de conversation — celle qu'on a quand un outil fait ce qu'il promet sans qu'on ait besoin de le dompter. Ce glissement, discret mais réel dans l'écosystème des startups et scale-ups européennes, mérite qu'on s'y arrête. Pas pour célébrer le nouveau venu, mais pour comprendre ce qu'il révèle de nos arbitrages en matière d'outillage.

Ce qui s'est passé, et pourquoi maintenant

Linear n'est pas une nouveauté. L'outil de gestion de projets logiciels existe depuis 2019, fondé par une équipe scandinave passée par Airbnb et Coinbase. Mais sa progression dans les équipes européennes s'est accélérée autour d'un moment précis : la migration forcée vers Jira Cloud et la dépréciation progressive des instances Jira Server on-premise, amorcée par Atlassian il y a quelques années et désormais consommée.

Ce n'est pas anodin. Jira Server permettait à des entreprises de contrôler leurs données, d'héberger sur leur propre infrastructure, de paramétrer finement les accès. Jira Cloud, c'est une autre logique : les données résident sur des serveurs d'Atlassian, majoritairement hébergés chez AWS, avec une localisation qui dépend des régions choisies et des contrats négociés. Pour beaucoup d'équipes qui n'avaient pas de contraintes réglementaires fortes, la question ne s'est pas vraiment posée. Elles ont migré vers le cloud, découvert l'interface vieillissante de Jira Cloud, ses temps de chargement perfectibles, sa complexité de configuration — et ont commencé à regarder ailleurs.

Linear est arrivé dans ce moment de vulnérabilité avec une promesse simple : un outil pensé pour les équipes d'ingénierie, rapide, opinionated, qui ne demande pas deux jours de configuration pour ouvrir un premier sprint. Le bouche-à-oreille a fait le reste, d'autant que la culture du partage d'outils dans les communautés tech européennes — Slack d'écosystèmes de startups, réseaux de CTOs, communautés comme Ramp ou Station F — amplifie ce type de signal.

Ce que ça change concrètement pour un DSI ou un CTO

La première chose à comprendre, c'est que Linear n'est pas un outil généraliste. C'est un outil pensé pour les équipes qui font du développement logiciel avec des cycles courts et des équipes resserrées. Si vous gérez un projet SI avec des phases longues, des intervenants multiples non-techniques, des workflows de validation métier complexes, Linear ne vous aidera probablement pas mieux que ce que vous avez déjà.

Mais si vous avez une équipe produit et engineering de dix à cinquante personnes qui veut aller vite et souffre du poids administratif de Jira, la question se pose différemment.

Et c'est là que l'angle souveraineté entre en jeu — naturellement, pas comme un argument de vente.

Linear est une entreprise américaine dont les données sont hébergées aux États-Unis. Point. L'outil ne propose pas, à ce jour, d'hébergement sur le sol européen ni d'instance dédiée on-premise. C'est un SaaS pur, fermé, sans option de déploiement alternatif documentée. Pour une startup qui gère son backlog de fonctionnalités et ses issues GitHub, c'est souvent acceptable — les données en jeu sont rarement sensibles au sens réglementaire du terme.

Mais dès qu'on monte en taille, qu'on intègre des informations clients dans les tickets, des données de sécurité dans les reports, ou qu'on opère dans un secteur régulé — santé, finance, défense, infrastructures critiques — la question du lieu de résidence des données redevient structurante. Et là, le charme de Linear se heurte à une réalité contractuelle et réglementaire qu'on ne peut pas contourner avec une belle interface.

L'autre dimension concrète, c'est la dépendance. Jira, malgré ses défauts, dispose d'un écosystème de marketplace, d'intégrations, d'API documentées, et d'une base d'utilisateurs suffisamment large pour que les compétences soient disponibles sur le marché du travail. Linear est plus récent, plus fermé dans sa philosophie produit, et son API, bien qu'existante, est moins mature côté intégrations enterprise. Choisir Linear aujourd'hui, c'est parier sur la trajectoire d'une entreprise qui n'a pas encore passé tous les tests du temps à grande échelle.

Ce n'est pas un argument pour ne pas le choisir. C'est un argument pour le choisir en connaissance de cause.

Le vrai débat sous-jacent : qui décide de l'outillage ?

Ce qui est intéressant dans la progression de Linear, c'est moins l'outil lui-même que le mécanisme par lequel il entre dans les organisations. Dans la majorité des cas, ce n'est pas le DSI qui a ouvert un appel d'offres. C'est un CTO de startup qui en a entendu parler, un lead dev qui l'a proposé, une équipe produit qui a convaincu sa direction technique. Linear progresse par capillarité, par adoption bottom-up — exactement comme Slack en son temps, ou GitHub avant lui.

Ce mode d'adoption pose une question de gouvernance que beaucoup de directions IT peinent encore à traiter correctement : comment encadrer sans brider ? Comment maintenir une vision cohérente de l'outillage sans se transformer en gendarmerie qui interdit tout ce qui n'est pas sur la liste approuvée ?

La réponse n'est pas dans la prohibition. Les équipes qui veulent utiliser Linear trouveront un moyen de le faire — avec leur carte de crédit personnelle si nécessaire, en attendant que la direction suive. La réponse est dans la qualification préalable : définir, en amont, quels critères font qu'un outil est acceptable ou non pour l'organisation, et rendre ce cadre visible et compréhensible pour les équipes techniques.

Ces critères peuvent inclure la localisation des données, les standards de certification de sécurité (SOC 2, ISO 27001), les clauses contractuelles sur la portabilité des données, la viabilité financière de l'éditeur, ou encore la disponibilité d'une clause de résiliation propre. Ils peuvent aussi inclure des critères d'interopérabilité : est-ce qu'on peut récupérer nos données dans un format standard si on décide de partir ?

Linear, sur ce dernier point, propose un export JSON. Ce n'est pas neutre — c'est mieux que rien, mais ce n'est pas non plus un format qui se réimporte facilement ailleurs.

Que faire si vous êtes en train de regarder Linear

Si vous êtes CTO d'une scale-up européenne et que vos équipes vous poussent vers Linear, voici comment j'aborderais la décision — non pas comme une liste de cases à cocher, mais comme une conversation à avoir.

Premièrement, cartographiez ce que vous mettez réellement dans vos tickets. Si vos issues contiennent des données clients identifiables, des informations de sécurité, des éléments couverts par le RGPD ou des réglementations sectorielles, le débat sur la localisation des données devient non négociable. Dans ce cas, Linear ne peut pas être votre réponse sans que vous ayez résolu cette question contractuellement — ce qui, aujourd'hui, n'est pas possible avec cet outil.

Deuxièmement, vérifiez que vous avez une stratégie de sortie documentée avant d'entrer. C'est valable pour n'importe quel SaaS, pas seulement Linear. Combien de temps faudrait-il pour migrer vos données vers un autre outil ? Avez-vous les ressources internes pour le faire ? La dépendance n'est pas un problème si elle est consciente et maîtrisée.

Troisièmement, parlez à vos équipes de ce que Jira résout encore que Linear ne résout pas. Pour des équipes purement engineering en mode produit agile, la liste est peut-être courte. Pour des organisations qui utilisent Jira comme hub central entre les équipes IT, métier, support et finance, la liste est probablement longue — et ce n'est pas Linear qui va la résoudre.

Il existe des acteurs comme Plane, un outil open source de gestion de projets qui se positionne explicitement comme une alternative à Jira avec la possibilité de self-hosting. Il n'a pas la finition de Linear, mais il répond à une contrainte que Linear ignore : le contrôle de l'hébergement. Ce n'est pas une recommandation, c'est une information : le marché n'est pas binaire.

Ce que ce basculement dit de notre rapport aux outils

La progression de Linear dans l'écosystème tech européen dit quelque chose de plus large que la simple qualité d'un outil. Elle dit que les équipes ont faim d'outils qui fonctionnent simplement, qui ne nécessitent pas une certification Atlassian pour configurer un workflow de base, qui répondent à leur réalité quotidienne sans leur imposer une philosophie projet héritée des années 2000.

C'est une critique légitime de la complexité accumulée de Jira. Mais c'est aussi un signal d'alarme pour les directions IT : si les équipes contournent les processus de validation outillage aussi facilement, c'est peut-être que ces processus sont perçus comme des obstacles plutôt que comme des garde-fous utiles.

La souveraineté numérique, dans ce contexte, n'est pas une injonction réglementaire abstraite. C'est une contrainte pratique qui doit être intégrée dans les décisions d'outillage au même titre que le coût ou l'ergonomie. Pas parce qu'un règlement l'impose — même si certains le font — mais parce qu'une organisation qui ne sait pas où sont ses données et qui les contrôle n'est pas une organisation qui maîtrise son risque.

Linear est peut-être le bon choix pour votre équipe produit en 2026. Mais ce choix mérite d'être fait les yeux ouverts, avec une compréhension claire de ce à quoi on dit oui — et de ce à quoi on dit oui sans forcément l'avoir décidé.