Analyse : La refonte d’une application

Analyse : La refonte d'une application

Analyse : La refonte d’une application

On vous a confié la charge d’un projet qui consiste à refondre une application ou un système informatique déjà existant et vous vous demandez comment aborder le sujet au mieux.

Tout d’abord, il vous faut commencer par bien comprendre le type de refonte qu’on vous demande :

  • Une refonte à l’identique, c’est-à-dire sans évolution majeure. Ce type de refonte correspond souvent à un changement de technologies lié à des problèmes d’obsolescence ou à des problèmes de performances.
  • Une refonte « évolutive », c’est-à-dire avec reprise de l’existant mais aussi avec intégration d’évolutions fonctionnelles ou techniques.

Une fois le type de refonte déterminé, vous devrez aussi définir le périmètre de la refonte ; c’est-à-dire déterminer :

  • Si c’est l’ensemble de l’application ou du système qui doit être refondu ou si c’est seulement une partie.
  • Si l’application ou le système doit s’intégrer avec de nouvelles applications ou systèmes ou s’il doit rester à l’identique au niveau de son environnement d’utilisation.

Pour l’application ou le système informatique, quel que soit le type de refonte, vous devrez, dans tous les cas, identifier, aussi bien sur le plan technique que sur le plan fonctionnel :

  • Les points forts ; c’est-à-dire les points qui donnent pleinement satisfaction aux utilisateurs et au client
  • Les points d’amélioration, appelés communément points faibles ; c’est-à-dire les points qui ne donnent pas satisfaction aux utilisateurs et au client
  • Les points manquants ; c’est-à-dire ce qui manque dans l’application. Dans le cas d’une refonte à l’identique, vous devrez uniquement vous concentrer sur les principaux points qui permettraient d’augmenter la productivité ou les performances. Pour une refonte évolutive, vous devrez essayer d’identifier, du moins au départ, le maximum de points.

Il est important de bien garder à l’esprit que l’analyse doit être effectuée aussi bien du point de vue de l’utilisateur final que du client. En effet, si on prend l’exemple de la refonte évolutive d’un site e-commerce, l’évolution peut aussi bien porter sur la partie utilisateur pour améliorer le fonctionnement du site du point de vue des acheteurs ou alors sur la partie back-office c’est-à-dire toute la partie technique qui est à destination du client (en l’occurrence du vendeur dans notre exemple).

Le cadre de votre projet étant défini, il vous faut maintenant vous lancer dans votre analyse proprement dite. Pour cela, il existe plusieurs techniques que vous pouvez utiliser :

  • Analyse documentaire : Cette technique consiste à étudier toute la documentation existante. Elle a pour objectif de vous permettre de déterminer l’ensemble des fonctionnalités existantes avec leur interaction les unes avec les autres. Elle vous permet aussi d’avoir une première vision globale de l’application ou du système à refondre. Bien évidemment, cette technique n’est réellement utile que si la documentation existante est à jour et est complète. Dans le cas contraire, cette technique ne vous donnera qu’une idée générale et probablement biaisée de la réalité.
  • Analyse de fonctionnement : Cette technique consiste à utiliser ou à faire utiliser, par un des membres de l’équipe projet, l’application ou le système pour en déterminer le fonctionnement mais aussi identifier, principalement, ses points forts et ses points faibles. Cette analyse de fonctionnement donne des résultats particulièrement intéressants lorsque les personnes qui réalisent cette analyse ne connaissaient pas l’application auparavant.
  • Analyse des usages : Cette technique consiste à étudier l’utilisation de l’application ou du système par les utilisateurs et le client dans leur quotidien. De manière pratique, cette analyse s’apparente à un audit des usages que nous décrirons plus en détail dans un autre article.
  • Analyse des attentes : Cette technique consiste à réaliser des interviews auprès des utilisateurs et du client pour connaître leur ressenti et leurs attentes par rapport à l’application ou au système. Ce type d’analyse se fait principalement à travers des interviews de différentes personnes qui connaissent et utilisent l’application ou le système au quotidien. En fonction du type de refonte demandée, cette analyse devra plus ou moins être poussée. Ainsi, dans le cas d’une refonte sans évolution, vous n’aurez pas besoin d’approfondir les points sur les fonctionnalités manquantes ou sur les nouvelles fonctionnalités souhaitées.

Une fois toutes les informations recueillies, vous devrez en faire une synthèse pour être en mesure de finaliser le cahier des charges fonctionnel de votre projet. La question qui se pose souvent ici est de savoir qui doit écrire le contenu du cahier des charges : les utilisateurs, le client, l’équipe projet ou un analyste externe. En fait, il n’y a pas de réponse absolue, tout dépend du contexte de réalisation du projet. Ainsi, si les utilisateurs ou le client ne sont pas en mesure ou en capacité d’établir un cahier des charges fonctionnels, l’équipe projet devra prendre en charge cette tâche. Si, dans votre entreprise, il existe un service de type AMOA (Assistance à Maîtrise d’OuvrAge), alors ce sera, probablement, à celui-ci à écrire le cahier des charges. L’important dans tout cela est de bien savoir qui va écrire le cahier des charges, sous quelle forme et dans quels délais.

Dans un prochain article, nous verrons comment formaliser un cahier des charges et surtout comment le faire valider.

Ce contenu a été publié dans Analyse, avec comme mot(s)-clé(s) , . Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *