Atlassian est facile à démarrer, difficile à faire durer

Les premières semaines d’une plateforme Atlassian sont souvent encourageantes. Une équipe crée un projet Jira, adapte un workflow, ouvre un espace Confluence ou structure un portail Jira Service Management. Le résultat est visible rapidement et répond à un besoin concret.

La difficulté apparaît plus tard, lorsque cette première réussite doit devenir un système partagé. D’autres équipes arrivent avec leurs contraintes. Les règles évoluent. Les intégrations se multiplient. Une configuration conçue pour vingt personnes doit rester lisible pour plusieurs centaines ou plusieurs milliers d’utilisateurs.

Le sujet n’est alors plus de savoir si l’outil fonctionne. Il est de savoir si la plateforme peut continuer à évoluer sans devenir incompréhensible.

La dette de configuration ne se voit pas immédiatement

Une nouvelle demande paraît rarement excessive prise isolément : ajouter un champ, dupliquer un workflow, créer un statut, accorder une exception ou installer une application. Chacune peut même être parfaitement justifiée.

La dette apparaît dans leur accumulation. Deux champs presque identiques finissent par porter des significations différentes. Un workflow copié cesse d’hériter des améliorations apportées à son modèle. Une automatisation contourne un problème local, puis devient une dépendance critique que personne n’ose modifier.

Cette dette n’est pas seulement technique. Elle produit des coûts très concrets :

• les utilisateurs hésitent devant des choix qui se ressemblent ;
• les administrateurs passent plus de temps à comprendre qu’à améliorer ;
• les changements deviennent risqués parce que leurs effets sont difficiles à prévoir ;
• les rapports rapprochent des données qui n’ont plus tout à fait le même sens ;
• les nouveaux usages héritent d’exceptions dont ils ne connaissent pas l’origine.

Une plateforme peut donc être disponible, rapide et sauvegardée tout en étant en mauvaise santé.

Mesurer la santé plutôt que le seul fonctionnement

Je trouve utile d’évaluer une plateforme selon cinq questions simples.

Les usages restent-ils compréhensibles ?

Une personne qui rejoint une équipe doit pouvoir comprendre où commence un processus, quelles informations sont attendues et ce que signifient les principaux états. Si cette compréhension dépend entièrement d’une transmission orale, la configuration ne porte pas seule son intention.

Les objets importants ont-ils un propriétaire ?

Un workflow, un schéma de droits, une automatisation ou une application critique doit avoir un responsable capable d’expliquer sa finalité et d’arbitrer son évolution. Sans propriétaire, l’ancienneté devient une raison suffisante pour tout conserver.

Les exceptions sont-elles explicites ?

Une gouvernance saine n’impose pas forcément un modèle unique. Elle distingue les standards, les variations nécessaires et les exceptions temporaires. Le problème n’est pas la différence : c’est la différence invisible, sans décision ni date de réexamen.

Les décisions peuvent-elles être prises sans expertise archéologique ?

Avant un changement, l’équipe doit pouvoir identifier les dépendances, les populations concernées et les conséquences probables. Si chaque évolution exige plusieurs jours d’enquête, la plateforme a perdu une partie de sa capacité d’adaptation.

Les équipes utilisent-elles réellement ce qui a été construit ?

Une fonctionnalité déployée n’est pas nécessairement adoptée. Les contournements par tableur, messagerie ou documents parallèles signalent souvent un écart entre le processus configuré et le travail réel.

Gouverner, c’est organiser les arbitrages

La gouvernance est parfois réduite à un comité qui approuve ou refuse les demandes. Elle est plus utile lorsqu’elle rend les arbitrages prévisibles.

Avant d’ajouter une nouvelle configuration, il faut pouvoir répondre à quelques questions : quel problème résout-elle ? Le besoin existe-t-il déjà ailleurs ? Peut-on étendre un standard ? Qui maintiendra la solution ? Comment saura-t-on qu’elle est encore utile dans un an ?

Ces questions ne visent pas à ralentir les équipes. Elles évitent qu’une réponse locale crée une complexité durable pour toute l’organisation. Elles donnent aussi aux administrateurs un cadre pour dire « oui, sous cette forme » plutôt qu’un choix binaire entre accepter chaque demande et figer la plateforme.

Un rythme de revue aide beaucoup. Il peut être trimestriel pour les objets les plus structurants et plus fréquent pour les automatisations ou intégrations critiques. L’objectif n’est pas de produire un inventaire exhaustif pour lui-même, mais d’identifier les éléments sans propriétaire, les doublons, les usages en recul et les décisions qui ne correspondent plus à la réalité.

L’adoption est un indicateur de conception

On présente souvent l’adoption comme une étape qui commence après le déploiement : communication, formation, support. Elle devrait aussi renseigner la conception.

Quand une équipe évite un champ, reconstruit un rapport en dehors de Jira ou conserve un espace parallèle, il faut comprendre pourquoi. Le problème peut venir de la formation, mais aussi d’une granularité inadaptée, d’un vocabulaire trop technique ou d’un processus qui exige trop d’efforts pour trop peu de valeur perçue.

Le retour sur une migration d’outil et la visibilité qu’elle doit rendre possible développe ce lien entre continuité, lisibilité et usage. Le projet de migration vers Xray montre également pourquoi une transformation technique doit être lue à travers ce que les équipes peuvent ensuite voir et faire.

Une discipline de durée

Faire durer une plateforme ne consiste pas à interdire le changement. Il faut au contraire préserver la capacité de changer : des standards assez clairs pour être partagés, des exceptions assez visibles pour être réévaluées, des propriétaires identifiés et des usages observés au-delà de la mise en production.

La qualité d’une plateforme Atlassian se lit moins dans le nombre de fonctionnalités activées que dans la facilité avec laquelle une organisation peut encore expliquer ses choix, les remettre en question et les faire évoluer.

Pour le cadre d’intervention de la société, la page expertise Atlassian d’Ovyka (s’ouvre dans un nouvel onglet) (opens in a new tab) présente les sujets d’intégration, de gouvernance et d’accompagnement, tandis que le guide pour choisir un partenaire Atlassian (s’ouvre dans un nouvel onglet) (opens in a new tab) détaille les critères à examiner selon le contexte.