Importance de l’analyse de l’existant

L’informatique d’une grande entreprise est souvent scindée en deux, avec d’un côté les équipes de développements qui constituent la maîtrise d’œuvre (MOE), et de l’autre la maîtrise d’ouvrage (MOA), en charge du besoin utilisateur. Ces personnes jouent notamment un rôle de facilitateur d’échange entre les directions métiers, donc les commanditaires, et les équipes techniques qui ne parlent pas toujours le même langage. En se concentrant sur les aspects fonctionnels du besoin, ils épargnent aux utilisateurs les contraintes techniques.

Sur ce projet, j’ai pu assumer différentes responsabilités, parmi lesquelles l’analyse du besoin, il a donc fallu travailler en étroite collaboration avec les utilisateurs pour être certain de ne rien omettre de leurs spécificités. La difficulté dans cet exercice consistait dans notre capacité à laisser s’exprimer l’utilisateur sur son besoin, et à le retranscrire sans déformer ses propos. Il faut se concentrer sur le besoin fonctionnel pour en décortiquer toutes les particularités qui pourraient avoir une incidence sur la conception et ainsi sur la souplesse, la stabilité et la finalité du produit.

J’ai pu constater après plusieurs réunions, que dans de nombreux cas nous n’obtenions pas toutes les informations de manière instantanée. Beaucoup d’utilisateurs vont éviter certains détails, sciemment ou non.

A mon sens pour certains utilisateurs il s’agit d’un simple oubli involontaire, et c’est aussi à la MOA de les amener à s’exprimer sur des choses auxquelles ils n’auraient pas pensé. Pour d’autres, les détails ne leur paraissent pas importants pour la conception de l’outil, et en abordant les détails, ils peuvent craindre de tomber dans d’autres débats houleux. Enfin et c’est plus inquiétant, nous pouvons aussi rencontrer des personnes qui ne connaissent pas le détail fonctionnel de leur métier. Il vaudra mieux dans ce cas s’adresser à des opérationnels.

C’est donc à la maîtrise d’ouvrage d’étudier l’existant, d’analyser les processus, de creuser le besoin. Tout doit être décortiqué pour faire apparaître les questions déterminantes et aboutir à un cahier des charges utile et suffisant pour pouvoir entamer les développements. Cet exercice est également un moyen pour la direction métier de poser le problème, et

d’imaginer des cas concrets et parfois inattendus. On a pu s’apercevoir en analysant l’existant, que dans de nombreux cas, aucune règle métier n’était établie de manière stricte, ou encore que des incohérences existaient. Pour exemple, les Actions de Contrôle Interne peuvent être traitées à des fréquences annuelles, semestrielles, trimestrielles ou mensuelles, et nous avons pu constater que les ACI relatives à la paye étaient Annuelles, alors que le traitement et, par conséquent, les contrôles se font tous les mois.

De la même manière, le passage d’une ACI du statut de clôturée (fin des contrôles) au statut supervisée (fin de la supervision) se fait par la transmission d’un fichier Excel. Le superviseur vise le document en ajoutant son nom et la date de supervision. Rien n’empêche le superviseur d’ajouter des contrôles, de les modifier même a posteriori… Si un contrôleur souhaite revenir ultérieurement sur un contrôle, aucun blocage applicatif ne l’en empêchera.

Les informations étant traitées sur des outils « ouverts » comme Excel, la direction métier a donc les marges de manœuvres nécessaires pour mettre en place une gestion des cas particuliers.

Dans le cas de ce projet qui consiste à transposer la saisie d’informations d’un fichier Excel vers un formulaire web avec un système de workflow, de nombreuses questions peuvent se poser. Les utilisateurs des caisses, habitués à leurs libertés de saisie sous Excel, seront maintenant soumis à des règles métiers strictes ; par exemple, lorsqu’une action de contrôle interne est supervisée, les contrôles ne peuvent plus être modifiés. Sous Excel, tout est basé sur la confiance. Il est précisé qu’un contrôleur d’un dossier ne peut pas en être également le superviseur. C’est dit, mais cela reste possible dans les faits car aucun contrôle ne peut être appliqué sur un tableur Excel, et cela devra le rester dans l’outil pour ne pas trop bousculer les modes de fonctionnement des contrôleurs en caisse.

3.1.2. Comment travaillez-vous ?

3.1.2.1. Structurer les processus existants

Le document regroupant le cahier des charges et les spécifications fonctionnelles a été rédigé dans un délai de 3 mois, au cours de différentes rencontres entre le DIL et un chargé de mission à la DAMR. A chaque nouvelle réunion nous éclaircissions les points en suspens, en posant tous les cas particuliers qui n’auraient pas été précisés. En jouant le rôle de MOA, je devais réussir à faire mûrir le besoin auprès de la direction métier. Le simple fait de poser par écrit le besoin ou le fonctionnement général du contrôle interne a suscité des avis divergents entre les parties prenantes. C’est donc bien le cahier des charges qui a pu préciser les points obscurs et qui a évité de construire une application bâtie sur un besoin mouvant, et qu’il aurait fallu sans cesse remanier par la suite. Le schéma ci-dessous est une belle caricature de ce que l’on peut vivre, et à la fois faire subir au client, si on n’écoute pas précisément son besoin, si on ne le reformule pas, si on ne lui fait pas valider, et si par la suite on ne le retranscrit pas correctement pour les autres membres de l’équipe.

Figure 7 : De l'expression de besoin à la réalisation (http://mathieuvigan.com/identification-des- besoins-du-client/)

3.1.2.2. La mise en place d’un outil impose la définition de

règles métiers strictes

C’est en exprimant leur mode de fonctionnement actuel, que la direction métier peut s’apercevoir que les règles déjà en place sont fragiles voire inexistantes, et qu’elles doivent maintenant être édictées pour assurer une cohérence d’ensemble à l’outil.

Les règles de gestion métier sont donc à établir, et doivent être strictes, et d’autant plus qu’il s’agit de faire respecter des processus métiers du contrôle interne. Une fois mises en place dans l’outil, elles pourront apparaître comme des contraintes auprès des utilisateurs, et seront à expliquer lors de la phase de présentation de l’outil et de la conduite du changement.

Pour que le lecteur puisse bien comprendre le sujet qui est traité, je propose dans le chapitre suivant, un résumé de l’expression de besoin qui a été faite.