La faute du client

Dans le monde de l’informatique, rien ne change jamais En tout cas pas à mon niveau. Les clients se plaignent de la même chose depuis les années 1970. Leur nouveau logiciel arrive trop tard, le projet de développement a coûté plus que prévu, et l’application ne fait pas ce dont a besoin l’organisation. De leur côté, les informaticiens reprennent toujours en choeur: c’est la faute du client – les clients ne savent pas ce qu’ils veulent.

Dans le monde de l’informatique, rien ne change jamais En tout cas pas à mon niveau. Les clients se plaignent de la même chose depuis les années 1970. Leur nouveau logiciel arrive trop tard, le projet de développement a coûté plus que prévu, et l’application ne fait pas ce dont a besoin l’organisation. De leur côté, les informaticiens reprennent toujours en choeur: c’est la faute du client – les clients ne savent pas ce qu’ils veulent.

Voilà le scénario. L’analyste arrive chez le client – une grande entreprise ou une institution publique. Il ou elle veut savoir comme le travail est réalisé aujourd’hui, et où le bât blesse. L’analyste demande quelles données sont stockées, quels processus métier sont réalisés, et quelle est l’intelligence de l’application existante. Et c’est là que les problèmes commencent. Le manager concerné n’est pas disponible. Les utilisateurs impliqués ne connaissent que leur propre tâche. Ils ne savent pas comment l’application calcule et raisonne, ils n’ont pas d’aperçu du processus métier dans lequel s’inscrit leur tâche. L’analyste doit faire un travail de détective pour trouver les réponses nécessaires. L’inspecteur Barnaby a toute notre sympathie; nous savons exactement ce qu’il ressent – les questions sans réponses, le manque de temps et la frustration.

L’analyste veut également savoir comment le travail sera réalisé à l’avenir. Un changement de logiciel est le moment idéal pour revoir le processus métier. Mais où va-t-il/elle trouver quelqu’un qui veut réfléchir à la question? Tous ceux qu’il/elle rencontre lui disent avec fierté et conviction: je n’y connais rien en informatique. Avant de décliner l’invitation à la réunion.

Les utilisateurs le savent : notre analyste est un garçon/une fille intelligente(e). Ils signent par conséquent le document d’analyse sans le lire. Les développeurs élaborent l’application décrite dans cette analyse. Lorsque la solution terminée est présentée aux futurs utilisateurs, ceux-ci comprennent pour la première fois en quoi elle consiste; et ils disent avec indignation: nous ne pouvons pas travailler avec ça! Perte de temps, frustration, coûts supplémentaires.

La réponse est simple

Les organisations doivent prendre leurs responsabilités. Les grandes entreprises et les organismes publics disposent généralement d’un calculateur à temps plein – quelqu’un qui réalise constamment des calculs sur les investissements de l’entreprise, les risques et les key performance indicators. Ils disposent également d’un responsable communication – comme ce pauvre gars de la SNCB qui devait faire croire pendant des semaines aux voyageurs que le Fyra roulerait un jour. Mais quand il s’agit du fonctionnement de l’entreprise – il n’y a personne. Seul l’organigramme est adapté.

Toute grande organisation devrait disposer d’une description de ses processus métier. Des données stockées. Des calculs réalisés – prix, TVA, remises, intérêts. Des applications utilisées. Et ce dans un langage que le personnel comprend. Malheureusement, ce travail est généralement réalisé (si toutefois il l’est) par un consultant externe hautement qualifié, qui n’éprouve aucune compassion pour les collaborateurs administratifs. L’homme en joli costume regarde de haut ces petites mains qui se sont arrêtées à l’enseignement secondaire. Ces personnes ne comprennent rien à ses présentations abstraites, aux cases à cocher et aux petites flèches. Et elles jettent l’éponge.

La seule méthode de travail qui marche est celle du “conceptual flow”, où l’analyste dessine le processus métier avec des personnes, un camion, un chariot élévateur, un lieu de stockage. Plus des documents et des ordinateurs. Personnellement, lorsque je travaille de la sorte, j’ai rapidement un feed-back précis de mes utilisateurs – quelle que soit leur formation. La majorité des utilisateurs sont très motivés et collaborent, si vous parlez leur langue.

Encore un inconvénient: après le départ du consultant externe, les modèles restent bien rangés dans l’armoire, ils ne sont pas mis à jour. On oublie de payer la licence des outils de modélisation. La poussière se dépose. Et le tout tombe dans l’oubli.

Ça fait trente ans que je travaille dans l’informatique, et rien n’a changé. Les utilisateurs ne comprennent pas que leurs données sont stockées dans une base de données (invisible pour eux). Que l’intelligence de l’ordinateur consiste dans une application logicielle qui a été écrite par un programmeur. Pour eux, l’ordinateur est une machine douée de raison.

Et maintenant? J’espère que les choses vont bouger. Qu’une organisation patronale ou qu’un établissement de formation va prendre l’initiative, et mettre en place un cours pour utilisateurs clés. En deux langues. A deux niveaux: débutants et avancés. Dans deux versions: secteur privé et secteur public. Si quelqu’un veut se lancer, je me ferai un plaisir de concevoir et donner le premier cours. Nous parviendrons peut-être ainsi à résoudre le problème de l’alignement business-IT. Et peut-être même la pénurie en informaticiens.