Le rôle du Business Analyst dans une équipe de maintenance logicielle

La maintenance évolutive et corrective est une activité de maintenance logicielle qui vise à maintenir et améliorer un système informatique existant. Elle peut être divisée en deux types distincts de maintenance, à savoir la maintenance évolutive et la maintenance corrective. En entreprise, la maintenance logicielle est souvent appelée le « RUN », et c’est une phase cruciale du cycle de vie d’une solution informatique qu’elle accompagne jusqu’à l’arrêt de son exploitation.

Le rôle du Business Analyst dans une équipe de maintenance est comparable sur le fond à celui de Business Analyst intégré à un projet « build » de conception / création d’un nouveau logiciel ou de mise en œuvre d’une évolution majeure. Il comporte néanmoins des différences significatives en termes d’organisation du travail, de périmètre métier et fonctionnel, d’urgence et d’activités réalisées. C’est ce que je vais vous expliquer dans cet article.

Pour commencer, je m’adresse à celles et ceux d’entre vous qui sont peu ou pas familiers avec les projets IT, et en particulier avec la façon dont se gère le cycle de vie d’un logiciel, depuis la naissance du besoin jusqu’à son démantèlement.

La maintenance logicielle : la maintenance évolutive et corrective

La maintenance logicielle évolutive est une activité qui vise à améliorer les fonctionnalités ou les performances du système informatique existant, en réponse à l’évolution des besoins de l’entreprise ou des utilisateurs. Elle peut inclure des mises à jour ou des ajouts de fonctionnalités, des améliorations de performance, de l’interface utilisateur etc. La maintenance logicielle évolutive peut être planifiée ou non, en fonction des besoins de l’entreprise ou des utilisateurs.

La maintenance logicielle corrective, quant à elle, est une activité qui vise à corriger les erreurs ou les bugs du système informatique existant. Elle peut inclure la correction de défauts de conception, de bogues de programmation, ou d’autres problèmes qui affectent la stabilité ou la performance (au sens large) du système. La maintenance corrective est généralement déclenchée sous forme de « tickets » en réponse à des plaintes des utilisateurs ou des résultats de tests de qualité.

En résumé, la maintenance évolutive et corrective est essentielle pour garantir le bon fonctionnement et la performance des systèmes informatiques existants. Elle peut aider les entreprises à s’adapter rapidement aux évolutions des besoins des utilisateurs et à résoudre rapidement les problèmes de performance ou de stabilité.

Miniature carrée F01

[Formation] Comment être rapidement opérationnel

Business Analyst en Systèmes d'Information DEBUTANT
2 heures de conseils pratiques pour identifier les informations initiales à recueillir, bâtir une première feuille de route claire de vos activités, et produire vos tous premiers résultats.

L’organisation de la maintenance logicielle

Les entreprises peuvent choisir de gérer la maintenance évolutive et corrective en interne ou de la confier à des prestataires de services spécialisés dans la maintenance de logiciels, c’est-à-dire :

  • Le service informatique au sein de l’entreprise ou de l’organisation cliente (le « client final »),
  • La société responsable de la création et production du logiciel (l’éditeur).
  • Un prestataire informatique tiers – en général une ESN (Entreprise des Services du Numérique, autrefois appelée SSII) – qui va se charger de la gestion de l’ensemble du système informatique et sera le point de contact avec les techniciens propres à chaque société de logiciel. Il s’agit alors d’un contrat de tierce maintenance applicative (TMA).

Lire aussi Les activités du Business Analyst débutant

Le Business Analyst en systèmes d’information qui intervient dans le cadre de la maintenance logicielle est donc soit rattaché à la DSI (Direction des Systèmes d’Information) du « client final », soit à la société éditrice du logiciel, soit à la société de prestation informatique (ESN) – le fameux « consultant informatique ».

Le Business Analyst peut avoir un contrat de travail avec l’une de ces parties, ou travailler comme indépendant. Dans le premier cas de figure, il touche un salaire, dans le second cas de figure, il facture sa prestation selon un taux journalier défini au préalable avec son client.

Le rôle du business analyst dans une équipe de maintenance logicielle

Le rôle du business analyst dans une équipe de maintenance logicielle est essentiel pour assurer la continuité et la chaîne de valeurs des activités de l’organisation cliente.

Il travaille en étroite collaboration avec les développeurs de l’équipe de maintenance logicielle pour comprendre les contraintes techniques, évaluer les problèmes remontés par les tickets, et proposer des solutions fonctionnelles adaptées. Selon les contextes, il peut soit travailler en direct régulièrement avec les « key users » métier pour mieux comprendre leurs besoins, soit seulement avoir des échanges ponctuels avec eux.

Il reste garant de la valeur ajoutée du logiciel dans les processus métiers des utilisateurs finaux.

Lire aussi Comment mesurer les performances avec des indicateurs [vision stratégique, indicateurs de performance, KPI]

Les responsabilités du Business Analyst dans l’équipe de maintenance logicielle

Dans le cadre de la maintenance applicative, les responsabilités spécifiques du business analyst peuvent varier en fonction des besoins de l’entreprise cliente, du contrat de maintenance liant éventuellement le tiers (société éditrice ou ESN) et le client final, et des exigences du projet « run ».

Pour résoudre les bugs et répondre aux besoins d’évolutions métiers mineures, et les activités du Business Analyst peuvent alors inclure :

  • L’analyse des besoins : Le business analyst doit comprendre les besoins de l’entreprise et des utilisateurs pour définir de quelle manière le logiciel sera corrigé ou amélioré. Ces corrections et évolutions sont majoritairement analysées « côté solution », par exemple en termes de fonctionnalités, de performance et d’interface utilisateur. L’analyse des besoins et processus métiers (côté pôles métiers et client) est moins prédominante comparativement aux projets de type « build ».
  • L’évaluation des impacts : à chaque réception d’un ticket de maintenance, le business analyst travaille en étroite collaboration avec l’équipe technique pour évaluer l’impact des changements demandés ou requis sur les systèmes et processus existants. Ainsi, à chaque fois qu’un « ticket » est créé et que, après une première brève analyse, celui-ci s’avère potentiellement impactant sur les besoins métiers, les fonctionnalités logicielles et/ou les exigences non fonctionnelles, le BA doit procéder à une analyse d’impact préalable à sa proposition de solution fonctionnelle.
  • L’élaboration de la documentation de conception: La proposition de solution fonctionnelle s’effectue au travers de la documentation des exigences fonctionnelles et non fonctionnelles, des exigences d’interface utilisateur et de tout autre élément pertinent du projet. En général, si la gestion de projet est faite de manière traditionnelle (cycle en V / cascade), il s’agit ici de mettre à jour les spécifications fonctionnelles détaillées, le glossaire, les règles métiers, la modélisation, les scénarios et cas de tests. Si le BA travaille dans une équipe agile de type SCRUM, il/elle sera en charge la plupart du temps de la rédaction de nouvelles user stories, et des critères d’acceptance.

[Master Class] Devenir Business Analyst en S.I.

Les Fondamentaux de A à Z
50 heures de formation qualifiante complète en e-learning pour se professionnaliser au métier de Business Analyst en systèmes d'information.

  • Les tests et la validation : Le business analyst peut être chargé de tester et de valider les modifications apportées aux systèmes logiciels pour s’assurer qu’elles répondent aux besoins de l’entreprise. A ce propos, on note la prédominance des tests de non-régression, car le BA doit constamment s’assurer que la mise en production d’un correctif ou d’une évolution mineure (même uniquement « technique ») n’a pas d’effets de bord et ne génère pas de nouvelles anomalies.

Lire aussi Les tests d’acceptation utilisateur (5 étapes)

  • La communication et la coordination : Le business analyst communique les besoins des utilisateurs et de l’entreprise à l’équipe de maintenance logicielle et assure la coordination entre les différents intervenants impliqués dans le projet. Son rôle au carrefour entre la technique, la gestion de projet et les utilisateurs métiers reste donc central.
  • L’ingénierie des exigences : comment s’assurer qu’une demande d’évolution métier ou le correctif d’un bug technique ne modifie pas accidentellement le besoin initial exprimé par le client et les utilisateurs, et la solution technique développée en réponse ? Comment vérifier qu’un nouveau besoin métier sera satisfait par une évolution logicielle en cohérence avec le logiciel existant ? C’est tout l’objet de l’ingénierie des exigences, qui trace d’une façon systématique le lien entre le besoin métier, les exigences fonctionnelles et non fonctionnelles, et le logiciel codé (ce qui est vérifié au travers des tests). Dans le cas où la documentation du logiciel est inexistante ou obsolète, les BA « maintenance » peuvent être  amenés à écrire des « rétro-spécifications » ou mettre en place un outil d’ingénierie des exigences.

La notion d’urgence et de criticité en maintenance logicielle

Comme pour tous les autres membres de l’équipe de maintenance, la notion d’urgence est très présente dans l’organisation du travail du business analyst.

En effet, le déclencheur de son action est un « ticket » créé soit par un utilisateur métier, soit par un des membres de l’équipe technique, à la suite du constat d’une anomalie ou d’un besoin d’évolution pour maintenir les conditions de service optimum.

La notion d’urgence et de criticité est donc cruciale :

  • Urgence de résoudre le ticket, en fonction de l’importance du goulot d’étranglement que le problème créé sur les processus d’entreprise ;
  • Criticité du problème en fonction des impacts sur les enjeux économiques de l’organisation.

A cela s’ajoutent les conditions contractuelles de réalisation de la maintenance, notamment dans le cadre le la TMA, qui définissent le temps alloué à la résolution d’un bug ou à la mise en œuvre de l’évolution logicielle.

Notez cependant que dans le cadre d’un fonctionnement dans une équipe agile, cette rapidité de résolution est inhérente au fonctionnement de l’agilité et à sa mise en œuvre au travers des sprints.

Dans le cadre de la maintenance logicielle, le Business Analyst est donc soumis à l’obligation de trouver des solutions rapidement lorsque le ticket est créé, et il/elle n’a pas forcément le temps de faire des analyses d’impact complètes – notamment dans le cas où le logiciel n’a pas été documenté ou lorsque les spécifications fonctionnelles détaillées et autres règles métiers ne sont plus à jour.

Il/elle se retrouve souvent à faire le pompier pour « vite » trouver une solution sans avoir eu le temps d’en explorer tous les recoins.

Pour conclure cet article, je m’adresse à celles et ceux d’entre vous qui ne connaissent la business analyse que dans le cadre de la maintenance logicielle : sachez que notre discipline prend un tout autre sens et élargit considérablement son périmètre dans le cadre de projets « build ».

La Business Analyse a un périmètre très vaste. Ainsi, même si elle est composée immuablement d’analyses, de recommandations, de conception détaillée de solutions, de vérification et de validation et d’accompagnement au changement, elle s’expérimente de mille et une manières, dont le contexte « maintenance logicielle » n’en est qu’une toute petite partie.

Soyez donc curieux et allez visiter les autres contrées inexplorées de la Business Analyse !

Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!

4 1 vote
Évaluation de l'article
Alice Svadchii

Alice Svadchii

Formatrice, coach, conférencière et productrice de contenus enthousiaste !

Cet article vous a plu? Partagez-le et suivez-nous sur les réseaux sociaux!

Découvrez des articles similaires

0
Would love your thoughts, please comment.x