Simplifier et prioriser sont les deux mamelles d’un projet réussi !*

** Voici un article invité de Thibault PAIRIS ! Excellente lecture ! **

« Votre plus grande erreur sur un projet », c’est le thème que m’a donné Jean-Philippe pour publier un article sur la gestion de projet. En lisant le sujet, me voici redevenu petit garçon, me tordant les mains, les joues rougissantes, en train de réfléchir à avouer ou non ma faute… Dur, dur de se livrer ! Et puis finalement, pas vraiment : savoir avouer ses erreurs, évaluer ce qui est allé de travers, et prendre les mesures pour que ça ne se reproduise pas : c’est aussi ça, être un bon chef de projet.

Le projet dont je vais vous parler était simple : créer une application de saisie de données quotidiennes. Sans entrer dans les détails, l’objectif était de consolider les données de fonctionnement de machines de production situées sur des sites industriels. Cette particularité créait des contraintes importantes :
– les ordinateurs sur sites n’étaient pas connectés à internet ou l’intranet de l’entreprise.
– installer une application n’était pas souhaité (trop d’ordinateurs différents à gérer, pas de support informatique sur place).
– il y avait 200 à 400 valeurs distinctes à entrer tous les jours.
– il fallait que les données saisies soient centralisées dans une base de données de la société, située elle sur l’intranet.

Le coeur du projet était donc un peu paradoxal. Il fallait saisir des données sur des ordinateurs sans connexion réseau, et les transférer sur une base de données connectée… Pour résoudre ce problème, nous avons réfléchi à une solution qui répondait bien aux contraintes du projet :
– créer une interface web déconnectée légère : juste une page web (html) locale à l’ordinateur, avec du code client (javascript) pour des petits contrôles de données basiques.
– cette interface déconnectée permet d’exporter toutes les données dans un fichier de transfert, avec une chaîne de contrôle du fichier pour éviter qu’il ne soit corrompu ou trafiqué.
– le transfert des données est effectué par un moyen physique : clé usb par exemple.
– enfin, les données sont intégrées dans l’intranet, qui permet toutes les fonctionnalités « lourdes » demandées : consolidation mondiale, recherche, export PDF, etc.

Cette architecture comportait des limitations. Par exemple, il ne nous était pas possible d’effectuer beaucoup de contrôles de données. En effet, tout le code était exécuté côté client, donc sur l’ordinateur peu puissant de l’opérateur de saisie. Si nous lancions des contrôles de cohérence complexes, le risque était de faire crasher son navigateur internet.

Face à cette interrogation, le métier s’est voulu très rassurant : « aucun contrôle nécessaire, les utilisateurs savent très bien quoi saisir dans chaque champ !« . Mais il s’agissait de clients internes, c’est-à-dire de départements métiers clients du département informatique. Impossible, donc, de leur faire valider le moindre engagement par écrit : « c’est entre nous, on ne va pas faire de la paperasserie » ! Pour leur permettre de se projeter dans le futur projet, j’ai tout de même pris quelques jours pour créer une maquette de l’interface. Elle était basique : tous les champs, mais des fonctionnalités assez limitées. Le résultat les a emballés ! Pour tout dire, le projet leur paraissait déjà terminé et prêt à être utilisé.

Nous nous lançons donc dans le développement. L’interface déconnectée est un peu rudimentaire, mais les fonctionnalités principales sont déportées sur le site intranet qui reçoit les données. A partir de cet intranet, on peut réaliser à peu près tout ce qui est demandé.

Bref, un projet rondement mené ! Nous sommes donc appelés à défiler dans les couloirs de l’entreprise sous les acclamations des salariés, on nous offre un voyage all-inclusive aux Bahamas et toute mon équipe obtient une augmentation substantielle… euh non, revenons à la réalité : la suite du projet fut à des années-lumières d’un tel dénouement !

Quand le client ne veut pas se lancer dans les tests …
Les tests métiers commencent donc : nous leur faisons une démonstration de comment tester et des types de problèmes à rechercher, puis nous les laissons prendre en main l’application. Rapidement, nous recevons des retours liés aux graphismes. Par exemple, nous avons repris en haut à gauche le logo de l’entreprise qui était affiché sur les anciens formulaires papier destinés à saisir ces données. La position de ce logo donne lieu à d’innombrables retours :
– il faut l’aligner avec le titre.
– si on redimensionne la fenêtre, le titre passe en-dessous du logo, alors qu’il devrait rester à droite.
– il faudrait décaler le logo de 5 pixels à gauche, c’est possible ?
– puis, une fois ces ajustements terminés : on a revu l’affichage du rapport avec le responsable du département, il veut utiliser un autre logo.
– et rebelote…
Autre exemple, il est possible d’exporter les données dans un fichier de tableur (Excel). Le nom de ce fichier fait débat :
– faut-il « Nom du site – Rapport – Date au format YYYY-MM-DD » ?
– ou bien « Rapport – Date au format DD/MM/YYYY – Nom du site » ?
– ou bien « Rapport #(numéro du rapport) – Nom du site – Date au format YYYY-MM-DD » ?
Plusieurs semaines passent sur ce type de retour. A chaque fois, nous demandons s’il n’ont pas trouvé des bugs plus importants concernant la sauvegarde des données, la génération du fichier de transfert, l’intégration des données dans l’intranet. La réponse est invariablement que les problèmes déjà remontés sont les seuls et sont critiques pour l’application. Personne ne pourra s’en servir si le logo n’est pas bien aligné !

Après cette première phase apparait un nouveau type de retour. Vous rappelez-vous ce que nous avait dit le client : « aucun contrôle ne sera nécessaire, les utilisateurs savent quoi saisir » ? Finalement, des contrôles étaient nécessaires :
– un contrôle sur la valeur du pH
– un contrôle sur le nombre de décimales
– un contrôle sur la durée totale des opérations qui ne doit pas excéder 24h par jour
– un contrôle sur la cohérence entre les heures saisies et la durée de chaque opération
– un contrôle sur la cohérence du nombre de lignes entre différents tableaux affichés
– etc. …
Après plusieurs mois de développement, le code dynamique sur l’interface déconnectée atteint deux tiers du code total de la page. Certains testeurs remontent alors des problèmes de performances. Exactement ce que nous avions anticipé lors de notre analyse initiale, et un comble pour une interface déconnectée qui devait rester rudimentaire !

Le coup de grâce vient avec les demandes techniquement irréalisables dans l’architecture retenue :
– pouvoir sauver un fichier sur le disque avec le raccourci ctrl+s… ce qui est impossible avec le code javascript d’un ordinateur, puisque accéder aux fichiers de l’ordinateur client serait une faille de sécurité.
– pouvoir générer un rapport PDF complet depuis l’interface déconnectée.
– etc.
Après 6 mois de tests, c’est le moment où il a fallu se résoudre à demander un arbitrage hiérarchique.

Une réunion de concertation inter-départements et de nombreux compromis plus tard, il a été possible de finaliser le projet et le mettre en production. Mis à l’épreuve par des centaines d’opérateurs, des bugs critiques sont ressortis et ont été corrigés. Aujourd’hui, l’application fonctionne parfaitement en production et ses utilisateurs l’apprécient. Cependant, nous n’avons pas encore eu de nouvelles de notre voyage all-inclusive aux Bahamas.

Ce que je retiens de ce projet, c’est qu’il aurait fallu :
– simplifier beaucoup plus la première version de l’application, pour valider le concept dans un premier temps.
– prioriser les tâches afin de privilégier ce qui apporte un gain net à l’entreprise.
– nommer un sponsor du projet, qui soit une personne extérieure au projet et capable d’arbitrer les différends.

Pour en savoir plus, et si vous avez déjà lu deux fois tous les articles de Jean-Philippe, n’hésitez pas à venir me rendre visite sur http://www.rocketprojet.com !

Et si vous recherchez une méthode de gestion de projet facile pour débuter en évitant tous ces problèmes, vous pouvez consulter mon livre paru aux éditions ENI.

– Thibault Pairis

* Le titre est une référence à une citation du surintendant des Finances Sully, au 17e siècle :
« Labourage et pâturage sont les deux mamelles de la France ».
 
Pourquoi ? Parce que la hauteur de vue nécessaire pour gérer un projet vient notamment avec la culture générale 🙂
 
 
 

1 réflexion au sujet de « Simplifier et prioriser sont les deux mamelles d’un projet réussi !* »

  1. Pour ce type de projet, j’ai une approche MVP. Je prévois plusieurs lots dont chaque lot est corrigé en fonction des retours du premier.
    En expliquant la démarche, je trouve que ça permet par exemple de calmer les attentes. On peut faire passer la « charte » après les fonctionnalités sans sacrifier l’ergonomie (dans l’exemple de l’article)
    Et je trouve que ça répond à la problématique de simplification et de priorisation.

    Répondre

Laisser un commentaire