Poussés par les équipes, les outils de la suite Atlassian ont depuis quelques années trouvé leur place dans les organisations, que ce soient des PME ou des grands comptes. Leur facilité d’utilisation et rapidité de configuration ont assuré leur adoption par les utilisateurs. En plus de cela, le coût attractif, tant en licence qu’en effort de mise en œuvre, permet aux équipes d’intégrer l’achat des solutions dans leur budget projet.
C’est dans ce contexte que ces solutions se sont tout naturellement développées et étendues dans les entreprises.
Cependant, ce phénomène a une conséquence majeure. Dans certaines sociétés, la DSI ignore l’existence de ces outils ou encore leur utilisation réelle.
Et comme tous les outils, ceux proposés par Atlassian ont leurs limites. Nous pouvons regretter l’absence de certaines fonctionnalités. Par exemple, combien de chefs de projet n’ont pas souhaité utiliser Jira comme un outil de reporting statistique ? Ou encore Confluence comme GED ?
L’écosystème Atlassian est né
Ces nouveaux besoins ont parfois été considérés à tort comme des lacunes de l’outil. Un vaste écosystème d’éditeurs s’est développé peu à peu afin d’apporter des solutions via des extensions légères, flexibles et facile à mettre en œuvre (ou pas…).
Les équipes ont pu enrichir leur Jira ou encore leur Confluence, sans rechercher des solutions d’intégration avec des solutions existantes dans leur SI.
Mais cela a un prix :
- ces extensions ont un coût non négligeable, pouvant parfois dépasser celui de l’outil Atlassian.
- le cumul de multiples extensions conduit à l’alourdissement de l’administration et des performances de Jira ou de Confluence.
Cela ne va-t-il pas à l’encontre des éléments qui avaient séduit et convaincu les équipes de faire des solutions Atlassian leurs outils privilégiés ?
Les pratiques changent
Les outils Atlassian, introduits auparavant dans l’ombre par les équipes, sont aujourd’hui mis en lumière. Ils deviennent visibles par l’ensemble de l’organisation, grâce notamment à leur reconnaissance par des cabinets tels que Gartner ou Forrester… Mais surtout à cause des tarifs qui subissent progressivement des hausses significatives ! Car bien évidemment, ils ne permettent plus aux projets de prendre le budget à leur charge.
De ce fait, la question de leur place dans le SI se repose alors, beaucoup plus insistante. Et les réponses apportées par les extensions deviennent obsolètes.
Prenons un exemple en guise d’illustration. Une majorité de de clients de SmartView sont utilisateurs d’Office 365. Ils développent et entretiennent depuis des années des compétences sur ces solutions. Ils financent des prestations d’accompagnement ou de développement pour une totale adéquation avec leurs besoins.
Ainsi, plutôt que d’enrichir Jira et Confluence avec des add-ons complémentaires, le bon réflexe ne serait-il pas de chercher d’abord une solution dans les outils en place ?
Un cas concret : les besoins de reporting
Jira dispose d’excellentes fonctionnalités de suivi d’indicateurs opérationnels. Cela permet de voir quels développeurs travaillent sur quels projets, si des demandes sont en attente, quel est l’avancement de la réalisation, …
Cependant, Jira n’est pas un outil de Business Intelligence (BI). Il ne permet pas nativement de produire des tableaux croisés dynamiques ou de faire des calculs de sommes ou de moyennes sur des périodes de temps configurables.
Or, pour permettre une analyse de sa performance et la mise en place d’indicateurs pointus, ces fonctionnalités deviennent nécessaires.
En ce sens, dans une organisation utilisant par exemple la suite Office 365, PowerBI (outil de data vizualisation) nous apparait comme la solution privilégiée. La mise en œuvre d’une interface entre PowerBI et Jira est un investissement plus profitable que l’ajout d’une extension de reporting spécifique.
Les solutions d’intégration avec les outils du SI
Typiquement, des plug-in complètent les fonctionnalités Atlassian. Or on voit souvent les limites.
Intégrer la suite Atlassian avec une approche microservices en utilisant MS Flow simplifie l’intégration.
Il est rare dans une organisation de constater une totale séparation de Jira avec le reste des activités. On peut identifier des besoins d’intégration avec un outil de gestion de relation client (CRM) ou encore de gestion de services informatiques (ITSM). Eh oui, tout le monde n’utilise pas – encore – Jira Service Desk 
!
Plus rare mais possible : des organisations souhaitent des échanges de données entre différentes instances Jira gérées par des filiales distinctes.
Dans tous ces cas, il existe des extensions permettant de faire communiquer ces applications. Mais bien souvent, ces dernières sont développées par différents éditeurs et restent spécifiques. Cela nécessite un investissement complémentaire sur la montée en compétence des équipes.
Ces solutions freinent également l’organisation dans la mise en place d’une vision claire, simplifiée et maitrisée des connexions entre les applications du SI.
Or, Office 365 par exemple propose MS Flow. Cette solution permet d’interconnecter des applications dès lors qu’elles sont accessibles, notamment au travers d’une API REST. Le tout, sans avoir recours à un nouveau fournisseur. Et parfois sans même avoir à acquérir des licences complémentaires ni à développer de compétences spécifiques.
Notre positionnement
De nombreux adages[1], proverbes, ou principes[2] tendent à penser que nous devons réserver les outils à l’utilisation pour laquelle ils sont faits.
En parallèle, DevOps encourage le développement de composants intégrés. Ces composants se concentrent sur ce qu’ils savent bien faire (architecture micro-services).
Ainsi, je privilégie cette approche plutôt que l’enrichissement systématique des outils Atlassian par des extensions. Les bénéfices sont doubles :
- réduction des risques par une moindre dépendance aux éditeurs
- optimisation des investissements financiers et de développement des compétences internes.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
Saint Exupéry
[1] « Small is Beautiful »
[2] Principe KISS : https://fr.wikipedia.org/wiki/Principe_KISS
Source 1ère image : Team par Vecteezy (https://fr.vecteezy.com/vecteur-libre/team)
