Retour aux ressources
Informatique, barrière ou facilitateur.
gestion de projet digitalisation 15/09/2021’informatique, c’est beau sur le papier, mais en réalité, cela ne fonctionne jamais lorsque l’on en a besoin !! » Qui n’a pas entendu une remarque de ce type ? Il est vrai, l’informatique est souvent mal perçu : vu comme un outil compliqué, et pourtant incontournable. Et bien qu’il s’impose de plus en plus dans tous les secteurs, au point de bientôt remplacer certains métiers (voir un cas extrême : Une assurance au Japon prévoit de remplacer 34 de ses agents par une intelligence artificielle, source : www.developpez.com ), nous oublions souvent un point fondamental dans l’informatique : il ne s’agit que d’un outil… Il ne nous viendrait pas à l’idée de se plaindre de l’arrivée du robot/pétrin/mixeur/cuiseur/multifonction dans une cuisine (oui, j’adore mon Kenwood Cooking Chef ).
Pourquoi vit-on la mise en place d’outils informatiques d’entreprise plus mal que d’autres outils ?
Il faut revenir à notre définition de l’outil informatique : dans le monde « réel », nous avons de bons réflexes pour faire effectuer des projets complexes :
- pour construire une maison, s’adresser à un architecte : il habite probablement lui aussi une maison, il sait travailler avec divers « experts » du bâtiment et les coordonner,
- pour faire réparer une voiture, s’adresser à un garagiste : il sait ce qu’est une voiture,
il en conduit probablement une, il connaît le fonctionnement et sait faire intervenir son réseau de constructeur et obtenir les pièces détachées nécessaires, - pour acheter un dessert, s’adresser à un pâtissier : il sait ce qu’est un gâteau et, … je suppose… les goûtes et en mange régulièrement
- … et naïvement, pour fabriquer une application, s’adresser à un développeur informatique…
C’est à la fois vrai et très… TRES réducteur : en 2015 l’OPIIEC recensait 171 fiches métiers dans le domaine du numérique… Il n’est pas choquant qu’un informaticien développant un outil de comptabilité ne connaisse rien en gestion, ou qu’un développeur sur un outil de supply chain n’ait jamais mis les pieds dans un stock…
Supposer que l’informaticien connaisse l’usage de son application correspond à supposer que le concepteur d’un tournevis sache… construire une montre, assembler un meuble en kit, et installer un tableau électrique… car après tout, il ne s’agit que de trucs avec pleins de vis…
Il y a un véritable problème d’adaptation de compétences : un développeur informatique est tout d’abord… un informaticien. Pour qu’il soit efficace, il faut l’entourer des bonnes personnes. C’est de là que vient la qualité de l’outil fini.
Ensuite, il y a la mise en place : en règle générale, les étapes classiques sont les suivantes :
- Constituer un cahier des charges, il s’agit d’une formulation, dans un document plus ou moins (souvent moins) concis, des objectifs et besoins auxquels doit répondre l’outil informatique.
- Passer par une étape d’évaluation / décision des différents outils, prestataires d’intégration / développement possibles pour arriver à un choix.
- Etablir des documents contractuels permettant de définir ce qui sera fait techniquement, par qui, sous quels délais et sous quelle responsabilité
- Etablir une liste des personnes prenant partie dans la mise en place (les chefs de projets côté client et fournisseur, les utilisateurs pilotes, …)
- Exécuter ce contrat par les différentes parties, c’est-à-dire mettre en place les paramétrages, développements, règles de gestion, les machines techniques permettant de faire fonctionner le système.
- Ouvrir le service, c’est-à-dire annoncer à tous les utilisateurs de l’outil qu’il est prêt et qu’il peut être utilisé, éventuellement, cette phase est accompagnée d’une documentation, des présentations et/ou des formations à l’outil.
Il y a donc une forte séparation entre le moment où les personnes clé du projet informatique, c’est-à-dire celles qui utiliseront l’outil sont sollicitées, parfois au tout début pour l’écriture du cahier des charges et à la toute fin lorsque tout est terminé, alors que plusieurs mois voire parfois plusieurs années se sont écoulées entre le besoin initial et la solution informatique : entre temps, les procédures ont changé et celles mises en place dans l’outil sont déjà obsolètes…
Formaliser la demande permettant de créer un logiciel, c’est prévoir d’utiliser un futur outil déjà obsolète.
Enfin la vision de l’outil informatique souffre aussi d’une vision « tout ou rien » : en effet, une fois une application déployée, il est « impensable » de continuer à utiliser des dossiers papier / crayon, même pour des cas complexes et non prévus dans l’outil.
Dans le monde réel, ce serait comme interdire à un bricoleur d’utiliser un tournevis dès qu’il a acheté une visseuse / dévisseuse électrique…
Certes l’informatique est un outil formidable, très complexe techniquement et nécessitant des compétences multiples dont les contours sont mouvants et pas toujours très clairs. Il faut revenir à une base qui est une évidence lorsque l’on oublie la technique :
Un outil ne peut être une barrière ou un facilitateur, tout dépend de l’être humain qui va piloter sa mise en place et son utilisation.
Voici les conseils que je peux vous donner pour vos prochains projets informatiques :
- Choisissez bien la ou les personnes qui vont piloter votre projet applicatif : elles doivent représenter les personnes qui vont utiliser votre application, c’est elles qui doivent impliquer les futurs utilisateurs du début à la fin du projet
- Formez les informaticiens au métier qu’ils vont outiller via un développement : avant de développer ou paramétrer quoi que ce soit, organisez des « ateliers découvertes », traitez-les comme des stagiaires ou de nouveaux embauchés devant apprendre VOTRE manière de traiter votre métier
- Prévoyez dès le départ que l’application ne gérera pas tous les cas et qu’il doit toujours y avoir moyen de fonctionner sans elle (conservez des dossiers papiers vierges, cela peut vous sauver le jour où il y a une coupure internet… )