Repartir de zéro n'est pas une solution

Publié il y a 3 ans par Quentin

J'ai eu une discussion intéressante avec l'équipe de développement que j'ai rejoint récemment. Cette équipe a pour but de fournir des outils afin d'aider au passage au tout numérique de l'entreprise. Cela passe bien sûr par faire des logiciels qui remplaceront des processus existants déjà en place.

Dans l'idée d'essayer de faire du bon travail, ils ont décidé de faire un outil qui permet de gérer une bonne partie d'un workflow majeur de l'entreprise, il permet de gérer les projets issus des ventes de l'entreprise.

On a tous souvent vu ça dans des entreprises; des logiciels qui ont pour but de vous accompagner dans tout votre travail de bout en bout. Vous commencez votre journée de travail en intégrant des données dedans et vous ne faites plus que suivre des écrans de status pour faire votre travail.

Dans l'idée, c'est plus facile pour les utilisateurs une fois l'outil maîtrisé et c'est plus simple pour gérer des cas comme des départs ou des absences de personnes.


Tout fiers d'avoir fait une première version de leur logiciel, ils m'expliquent avoir fait une démo au patron de l'entreprise qui leur a simplement répondu : C'est bien mais c'est pas complet.

Le reste du public de la démo était très enthousiaste sur l'utilisation du produit mais la démarche du chef était correcte à mon avis bien que pas assez explicite.


Lorsque l'on développe un logiciel, il faut se poser plusieurs questions :

  • Pourquoi développer ce logiciel ?
  • Pour qui ?
  • Dans quel but ?

Faire un logiciel sans savoir pourquoi n'est d'une part pas très motivant mais d'autre part, ça nous amène à facilement prendre des mauvaises décisions.

Savoir qui sera l'utilisateur du logiciel influence grandement les interfaces, la complexité et la quantité d'informations. Vous ne ferez pas la même interface pour un écolier que pour un ingénieur.

Le but d'un logiciel est important pour déterminer le scope des fonctionnalités ou même la qualité finale du produit. Si le but est de faire un traitement d'une centaine de fichier reçu une fois, il est peu important de traiter l'ensemble des cas. Si par contre le logiciel est destiné à un usage long terme, il faut alors miser sur la qualité, la maintenabilité et la souplesse.

Lorsque j'ai demandé à l'équipe pourquoi et dans quel but ils m'ont simplement répondu ce que fait le logiciel : pour gérer des projets. L'entreprise gère déjà aujourd'hui ses projets en interne et l'entreprise fonctionne suffisamment pour survivre. Changer la méthode pour changer la méthode n'est pas une bonne solution. Si je vous propose un téléphone pour remplacer votre actuel avec lequel vous êtes déjà content, il y a peu de chance que vous acceptiez de changer de téléphone.

Assez vite, on comprend ce qui ne va pas avec ce projet et pourquoi le patron considère qu'il n'est pas complet. Le logiciel ne cherche pas à répondre à un problème mais simplement à faire un des cœur de métier de l'entreprise.

Du coup, le programme qui a pris plusieurs semaines à être développé est en attente depuis plusieurs mois. Le patron est incapable de fournir une liste des choses qui manque et l'équipe de développement est frustrée.


Faire et intégrer un logiciel dans une entreprise est une chose compliquée. En tant qu'ingénieur, nous nous devons de comprendre que nous ne pouvons pas remplacer l'ensemble des outils de travail d'une personne parce que les nouveaux sont meilleurs. Le meilleur moyen de pousser à l'adoption d'un projet est de répondre à un problème.

Quels sont les problèmes de la gestion de projet actuelle ? Comment y répondre ? Peut-on alors développer une solution à un problème spécifique qui se greffe bien dans le workflow actuel ?

Il faut penser à changer le système qu'à partir du moment où vous êtes capable de le faire étape par étape. Jamais une équipe de technicien qui a travaillé toute sa vie avec les même outils décidera d'en changer parce que c'est mieux. Par contre, si vous proposez à ces même techniciens une méthode pour résoudre le problème de leur workflow actuel sans tout changer alors vous pourrez commencer pour voir pour améliorer le workflow global.

La productivité n'est pas qu'une question d'outils, c'est aussi une question de maîtrise des outils. Personne de saint d'esprit n'acceptera de tout changer dans son process de travail parce que c'est mieux(à part peut être des développeurs).


Pour conclure, ce qu'il faut retenir de cette histoire c'est que lorsque vous démarrer un projet pour remplacer un existant, posez vous les bonnes questions et observez les réponses. Ça ne sert à rien de repartir complètement de zéro si aucun utilisateur n'est près à le faire de son coté.