Alternatives à Jira pour les équipes qui ne font pas de développement logiciel

Cherchez « alternatives à Jira » et vous obtiendrez une bonne liste. Linear, ClickUp, Monday, Asana, tous très corrects... et tous essentiellement pensés pour des équipes qui raisonnent en sprints et en backlogs.

Aucun ne répond à votre question, parce que votre question ne parle pas de sprints. Elle parle du système qui suit trois cents dossiers de voirie, ou l'ensemble des qualifications fournisseurs, ou les inspections que votre auditeur voudra voir au printemps.

C'est une autre question. Voici comment la prendre, et ce que valent les candidats une fois qu'on la pose correctement.

Pour qui Jira est fait, et pour qui il ne l'est pas

Si votre équipe fait des sprints, vit dans Bitbucket et se mesure en story points : arrêtez ici. Atlassian a construit Jira pour vous, et rien dans cet article n'améliore votre situation. Restez où vous êtes.

L'article s'adresse à l'autre utilisation de Jira. Celle où les tickets ne sont pas des tickets. Ce sont des dossiers, des interventions, des non-conformités, des demandes, des candidatures, des inspections. Et les champs ne sont pas des estimations et des composants, ce sont un site, un prestataire, une échéance, un niveau de risque et quelqu'un qui valide.

Dans ces installations-là, Jira a fini par servir de registre de travail polyvalent. Ce qu'il peut faire, certes, mais ce qu'il fait cher et mal.

Ce à quoi les gens se servent vraiment de Jira

Chez les organisations avec qui nous parlons, nous observons les besoins suivants :

Un registre de travail récurrent. Voiries, maintenance de bâtiments, interventions sur un parc. Une carte par intervention, un statut, un site, un responsable.

De la conformité qu'il faut pouvoir montrer. Non-conformités, actions correctives, qualifications fournisseurs, validations. Le travail est ordinaire. L'exigence, c'est de pouvoir prouver plus tard qui a fait quoi et quand.

Des demandes internes. Services généraux, informatique, RH. Quelque chose arrive, c'est trié, c'est affecté, c'est clôturé, et quelqu'un veut un comptage mensuel.

Des projets, au sens large. Un portefeuille de dossiers parallèles, chacun avec quelques étapes, dont quelqu'un doit garder la vue d'ensemble.

Rien de tout cela n'est du développement logiciel. Tout cela rentre dans Jira, si l'on accepte de faire rentrer un carré dans un rond.

Pourquoi Jira convient mal ?

Jira n'est pas mauvais. Il est simplement bâti sur des hypothèses qui ne tiennent pas ici.

La configuration Jira est un métier. Workflows, écrans, configurations de champs, schémas de permissions. Changer ce qu'un formulaire demande, c'est le travail de l'administrateur Jira ou de l'IT, qui a sa propre file d'attente. Dans un registre qui évolue, une nouvelle catégorie de risque, un nouveau site, une nouvelle étape, cette friction s'accumule jusqu'à ce que les gens travaillent à côté de l'outil plutôt que dedans : vive le retour Excel !

Le vocabulaire est faux. Epics, stories, sprints, story points. Chaque personne que vous formez doit traduire. Une responsable qualité n'a pas de backlog ; elle a un plan d'actions correctives, et ce n'est pas un synonyme.

Le reporting suppose l'agilité. Burndown, vélocité, flux cumulé. Ce dont vous avez besoin, c'est le nombre d'interventions ouvertes par site, combien sont en retard, et un document à remettre à un auditeur.

C'est tarifé pour une échelle que vous n'avez pas. Le plus petit palier Data Center facture 500 utilisateurs, et les paliers plus petits sont partis avec Jira Server en février 2024. C'est le sujet de l'épisode précédent.

Les cinq critères

Si vous souhaitez réduire la friction dans vos équipes de suivi, et alléger votre facture, cherchez plutôt :

1. Un modèle que vos propres gens peuvent changer. La personne qui comprend le processus doit pouvoir ajouter un champ, un statut ou une catégorie sans ouvrir un ticket. Si la réponse à « on pourrait aussi suivre le prestataire ? » est un projet IT, l'outil choisi est le mauvais.

2. Des catégories qui portent du sens. Vous voulez filtrer, grouper et compter par site, par niveau de risque, par prestataire, par statut, et en combinaison, sans construire un rapport par question.

3. Une traçabilité montrable. Qui a changé quoi, et quand. Pas comme fonctionnalité pour développeurs. Comme la chose que l'auditeur demande.

4. Un reporting qui sort des données. Si vos chiffres mensuels sont assemblés à la main dans un tableur, vous n'avez rien remplacé.

5. L'endroit et la manière dont c'est hébergé. Des centres de données européens si ça compte pour votre service juridique, vos propres serveurs si ça compte encore davantage.

Notez ce qui n'est pas dans la liste : les intégrations avec l'outillage de développement, les cérémonies agiles, une marketplace d'applications. Ce sont les points forts de Jira, et cet usage n'en a aucun besoin.

Ce que donnent les candidats

Appliquons les critères. Les candidats se rangent en trois familles, et c'est le critère 5 qui les sépare le plus brutalement.

Les suites de travail génériques (monday.com, Asana, ClickUp, Smartsheet) sont excellentes sur les critères 1 et 2. C'est littéralement leur proposition : une responsable qualité y ajoute une colonne sans demander la permission à personne. Elles sont moyennes sur le 3, où l'historique existe mais n'est pas pensé pour être produit à un auditeur. Et elles échouent au 5 : aucune ne propose d'édition auto-hébergée, et toutes relèvent d'un droit non européen. monday.com propose une résidence des données en UE à Francfort pour les comptes Enterprise, ce qui est une vraie fonctionnalité sans être un changement de juridiction, comme nous l'avons expliqué.

Les gestionnaires de projet open source européens (OpenProject, Tuleap, Redmine) passent le critère 5 sans discussion : ils tournent sur votre matériel, et les deux premiers ont un éditeur européen identifiable derrière eux. Tuleap est solide sur le 3, la traçabilité étant précisément son terrain en milieu réglementé. En revanche, je les trouve plus faibles sur le critère 1 que leur réputation ne le suggère : modifier le modèle y reste un geste d'administrateur, pas de responsable métier. Vous aurez changé de fournisseur sans avoir changé la file d'attente. Deux épisodes leur sont consacrés : ce que leur exploitation coûte réellement et comment vérifier qu'un éditeur est bien européen.

Odoo est le cas à part : belge, open source, auto-hébergeable, très configurable. C'est aussi un ERP complet, donc un investissement d'une autre nature. Si vous en déployez déjà un, regardez-le sérieusement. Sinon, c'est beaucoup de machine pour un registre d'interventions.

Ce tableau vieillira : les sociétés se font racheter et les offres changent. Posez les questions vous-même plutôt que de recopier cette ligne-ci dans un cahier des charges.

Où se situe Klaro Cards

Nous sommes une société belge et nous construisons ça depuis 2017. Klaro Cards est un hub opérationnel pour exactement le travail ci-dessus : des cartes plutôt que des tickets, des dimensions plutôt que des schémas, un modèle que l'expert métier configure sans développeur, et des modules préconfigurés pour les processus qui reviennent.

Nous prétendons tenir les cinq critères ensemble sur la combinaison du 1 et du 5 : la configurabilité par le métier que les suites américaines font bien, avec l'hébergement européen ou sur vos serveurs que seul l'open source offrait jusqu'ici.

Il est utilisé par des collectivités, l'industrie, la pharma et des sociétés de services, hébergé dans des centres de données européens ou sur vos propres serveurs.

Nous ne remplaçons pas Jira dans une équipe de développement, et nous n'y tenons pas. Si vous avez les deux types d'équipes, la réponse honnête est probablement les deux outils, et c'est un meilleur résultat que d'en forcer un à vivre dans l'autre.

Si votre Jira est sous Data Center, le délai pour cette décision est plus court que vous ne le pensez : voyez le décompte.

Jira, Confluence et Atlassian sont des marques d'Atlassian. Klaro Cards n'est pas affilié à Atlassian. Les autres produits sont cités à titre de comparaison, d'après ce que leurs éditeurs publient à la date de rédaction ; vérifiez vous-même avant d'en faire un critère de marché.