Développement informatique d’une maquette

D’autres entrevues, ainsi que la présentation de prototypes de la maquette, ont permis d’affiner les besoins des futurs utilisateurs, ce qui nous a conduit à définir les caractéristiques principales que doit avoir l’outil.

5.2.1. Caractéristiques principales de la maquette et fonctionnement général

Caractéristiques demandées Solution correspondante

Accès facile et rapide aux processus, activités, ou indicateurs qui doivent être étudiés

A partir de la cartographie (connue de tous), l’utilisateur sélectionne le processus qu’il veut, puis il choisit d’accéder à la page décrivant les activités

Ajouter, consulter et stocker toutes les mesures des indicateurs

Formulaire de mesures à compléter et stockage grâce à une base de données

Enregistrer des commentaires et échanger des rapports pour avoir un historique des différentes actions menées

Page réservée à l’échange de commentaires et de documents

Résultats clairs et visuels Différents graphiques présentent les résultats Permettre de calculer la performance à

différents niveaux

Directement sur la maquette : évaluation de la crise et de chaque processus. Analyse plus fine possible en utilisant MACBETH.

Améliorer la collaboration et communication Outil accessible par tous à tout moment et possédant des zones d’échange d’informations

Générer des rapports

Possibilité d’export des tableaux de bord avec les mesures, des commentaires et des résultats d’évaluation

Tableau 43 : solutions techniques mises en place pour répondre aux demandes

Le fonctionnement général de la maquette est le suivant : dès qu’une crise survient, si une cartographie qui convient existe déjà dans la base de données, alors celle-ci est chargée avec ses processus et le SIP associé. Sinon, une nouvelle cartographie est créée. Ensuite, il faut dérouler notre méthode pour la création du SIP. L’outil est alors en service, c’est-à-dire que les utilisateurs peuvent commencer à saisir des mesures et observer les résultats. Une fois les mesures de la semaine (si la fréquence de mesure choisie est une semaine) saisies, l’outil calcule et affiche la performance sous forme de graphiques et de flèches (tendances) pour voir l’évolution des résultats et sous forme de feu tricolore pour voir l’état de performance actuel de la réponse.

La navigation dans l’outil se fait selon la Figure 62. Trois types d’utilisateurs ont été définis et ont des droits d’accès différents :

- l’administrateur : c’est la personne en charge du bon fonctionnement informatique de l’outil. Il a accès au code de l’outil et gère sa mise à jour. C’est l’administrateur qui met en ligne une nouvelle cartographie ou une copie d’une cartographie existante avec le SIP associé,

- le team leader : le travail de saisie des mesures lui est confié,

- les décideurs : ils ont un accès restreint aux pages de relevés de mesures, ils peuvent les consulter, mais pas les modifier.

Figure 62 : organisation de l’outil

Trois pages ont un accès restreint (réservé à l’administrateur), les autres sont accessibles par tous les utilisateurs. Deux pages sont dédiées à la collaboration : l’une permet l’échange de documents (n° 7), l’autre permet l’échange et le partage de messages et de commentaires (n° 6). Ensuite, cinq pages (n° 1 à 5) sont dédiées à l’évaluation de performance. Ces pages sont détaillées dans la partie 4.2.3.

5.2.2.Logiciels et langage utilisés a. Architecture

L’architecture choisie pour l’outil APARU est l’architecture MVC (Modèle-Vue-Contrôleur), qui sépare les données (le modèle), l'interface homme-machine (la vue) et la logique de contrôle (le contrôleur).

Figure 63 : architecture MVC [Site 5, 2012]

Ce modèle de conception impose une séparation en trois couches :

- le modèle représente les données de l'application. Il définit aussi l'interaction avec la base de données et le traitement de ces données,

- la vue représente l'interface utilisateur, c’est-à-dire ce avec quoi il interagit. Elle n'effectue aucun traitement, elle se contente d'afficher les données que lui fournit le modèle. Plusieurs vues peuvent présenter les données d'un même modèle,

- le contrôleur gère l'interface entre le modèle et le client. Il va interpréter la requête de ce dernier pour lui envoyer la vue correspondante. Il effectue la synchronisation entre le modèle et les vues.

b. Code

Sur demande du service informatique de la CRF, le code a été réalisé en php. Pour la création de l’outil, un « framework », c’est-à-dire un cadre pour le développement, a été utilisé : CodeIgniter. Il s'agit d'une boîte à outils d'aide à la construction de sites web. C’est un ensemble de codes qui fournit une organisation ainsi qu'un grand nombre de fonctionnalités. Son but est de permettre d'améliorer le temps de développement projet en fournissant un ensemble complet de bibliothèques, prenant à leur charge les tâches les plus répétitives et en offrant une interface simple et une structure logique pour utiliser ces bibliothèques.

c. Images des processus et activités

Les processus sont réalisés avec le logiciel bizAgi (logiciel de modélisation libre), puis importé sous forme d’image (.PNG) dans le code.

d. Graphiques

Les graphiques sont générés grâce à Artichow, qui est une librairie qui permet de créer des graphiques avec le langage PHP. Il est notamment possible de générer des courbes, des histogrammes, mais aussi des formes diverses. Le code, pour créer les graphiques, est directement développé dans les fichiers PHP.

e. Base de données

Le système de gestion de base de données utilisé est mySQL. Le schéma conceptuel de la base de données de l’outil est montré sur la Figure 64, pour expliquer le lien entre un processus, un indicateur et la crise. Un indicateur appartient à un processus, qui appartient lui-même à une crise. Différentes tables ont été créées :

- table crise : elle permet de gérer toutes les données générales de la crise,

- table type crise : elle permet d’attribuer un type à une crise (par exemple, crise de type naturel),

- table région : elle gère les zones géographiques définies par la CRF, on peut ainsi afficher sur l’outil le lieu de la crise,

- tables fuseau et zone heure été : une horloge donnant l’heure à Paris et l’heure sur la zone est affichée sur les pages de l’outil. Pour permettre cet affichage, ces tables gèrent le fuseau horaire et la zone d’heure d’été (pour connaître la date de passage, s’il y a, à l’heure d’été et à l’heure d’hiver),

- tables utilisateurs, statut et avoir droit accès : elles gèrent les données des utilisateurs et leur statut (administrateur ou utilisateur). La table avoir droit accès gère les droits d’accès des utilisateurs,

- table processus : elle gère les données sur les processus (nom, nom de la cartographie à laquelle il appartient, pilote…),

- table indicateur : elle gère les indicateurs (intitulé, fréquence de mesure…),

- table commentaire : elle gère les commentaires laissés par les utilisateurs,

- table fichier : elle gère les fichiers déposés par les utilisateurs. A chaque nouveau dépôt, le numéro de version du fichier est modifié. La table type de fichier gère les types de fichier,

- table renseigner : elle stocke les mesures des indicateurs entrées par les utilisateurs et les renseignements concernant la mesure (date, indicateur concerné…).

5.2.3. Description des pages principales

Comme l’indique la Figure 62, les acteurs peuvent accéder aux différentes pages de l’outil (tableaux de bord, mesures, processus et évaluation) depuis la page d’accueil (n° 2).

• Page « mesures » Figure 65 : cette page est utilisée pour (1) saisir les mesures prises pour chaque indicateur des processus suivis et (2) déposer des commentaires concernant les mesures. La CRF a choisi une période d’une semaine pour les mesures, c’est-à-dire que les acteurs doivent rentrer les mesures une fois par semaine. Il est possible de modifier les valeurs mémorisées en cas d’erreur. L’outil renseigne les utilisateurs sur le pourcentage de mesures saisies et les calculs prennent en compte, si besoin, le fait qu’il manque des mesures.

Figure 65 : page « mesures »

• Page « processus » Figure 10 : cette page donne accès au détail des différentes activités qui composent le processus sélectionné par l’utilisateur. Dans la version actuelle, les indicateurs mis en place sont directement liés aux processus critiques. Il est toutefois possible de positionner les indicateurs au niveau des activités. Cette solution n’a pas été retenue, car la CRF préférait travailler au niveau processus.

Figure 66 : page « processus »

• Page « évaluation » Figure 67 : l’outil capitalise les données entrées dans la page de mesure, en fait une analyse et affiche les résultats sur cette page « évaluation ». Il est possible de déposer des commentaires, qui sont téléchargeables.

Figure 67 : page « évaluation »

• Page « tableaux de bord » Figure 68 : permet l’affichage des résultats de performance de chaque processus et du résultat global pour toute la réponse. Il est possible d’importer ses résultats pour créer des rapports. Cette page est utile, car elle permet (1) d’avoir une vision globale des résultats et donc de détecter les problèmes, (2) de montrer les résultats aux donateurs pour qu’ils voient que la réponse est correctement suivie. Il est possible aussi de leur imprimer un rapport contenant uniquement les indicateurs liés à l’aspect financier. Et (3) de garder une trace des résultats à un moment donné. Ces trois buts sont très importants pour les humanitaires.