« C’est l’algorithme qui l’a dit » ou la déconnexion du logiciel et du métier

badcomputerday

Les premiers retours d’APB, logiciel gérant les souhaits des élèves pour leurs études après le Bac, ont été publiés récemment, avec leur lot de retours négatifs et d’incompréhensions de la part d’étudiants et de parents mécontents du résultat final. Pour expliciter ce phénomène les commentateurs utilisent la formule « c’est un algorithme qui décide », comme si le destin de nos enfants dépendait du bon vouloir de froids circuits imprimés. J’ai même entendu sur une radio une mère indignée menacer sur un ton mi-humoristique « si je trouve l’ordinateur qui a fait cela, que je lui explique ma façon de penser ».

Cette réaction est assez classique quand la décision est prise par un système informatique : celle-ci prend un aspect arbitraire et injuste, parfois plus que quand elle est prise par un être humain. Cette vision est paradoxale car dans la plupart des cas (écartons les algorithmes neuronaux, mon directeur technique en parlera) l’ordinateur applique de façon impartiale et linéaire les règles qui lui ont été indiquées par ses concepteurs. Donc si une question doit être remontée, ce n’est pas au produit mais aux concepteurs des règles fonctionnelles qui le composent. Or après une longue période d’utilisation le logiciel est personnifié par son utilisateur, et se sépare de ses concepteurs.

Revenons au métier, et en particulier à une phase importante de la vie d’un logiciel métier : le moment où la grande majorité (voire la totalité) des utilisateurs d’une application ne connait plus les règles qui expliquent la réaction d’un logiciel.

Il m’est arrivé plusieurs fois, dans le cadre de projets qui durent plusieurs années, d’avoir à expliquer à mon client, qui connait son métier, pourquoi le logiciel, qui applique son métier, prenait telle ou telle décision. Aussi surréaliste qu’elle puisse paraître cette inversion des rôles est finalement assez compréhensible. Je vais dans la suite de cet article l’expliquer, et donner des clés ergonomiques et organisationnelles pour l’éviter.

La perte de contrôle

Pour comprendre cette perte de contrôle, revenons au principe d’une application métier : l’un de ses objectifs est de faire gagner du temps à utilisateur en appliquant plus efficacement les règles de son métier qui sont suffisamment systématiques et simples pour d’une part être applicables sans erreur, et d’autre part que le fait que ce soit un être humain qui l’applique n’apporte aucune valeur ajoutée. Par exemple, dans une application de validation de dossier de normes, il n’y a aucun intérêt à demander à un utilisateur de vérifier dans un dossier la présence d’un document, un ordinateur le fera plus rapidement. De la même manière, historiquement la première application qui a provoqué l’engouement pour les ordinateurs personnels (même maintenant d’ailleurs) est le tableur : pourquoi faire les calculs compliqués et inintéressants si un ordinateur peut les exécuter instantanément pour nous?

Lorsqu’un utilisateur appuie sur un bouton de son application des milliers d’actions et de calculs peuvent se déclencher en quelques millisecondes pour afficher à l’écran un oui ou non. L’utilisateur n’a aucun intérêt à refaire le calcul lui même, le résultat est fiable, et on a gagné des heures et des heures. Mais la conséquence de cela est que l’utilisateur, même s’il est au fait de par sa connaissance du métier des règles qui sont en jeu, finit par perdre de vue la série d’opérations qui est effectuée, et l’action devient quasiment magique (le terme de « bouton magique » a souvent été évoquée par nos utilisateurs pour décrire un composant de leur application).

Les cas typiques où cette incompréhension est particulièrement forte sont les cas particuliers d’utilisation de l’application. En effet dans un cas non usuel, l’utilisateur attend une réponse de la part du logiciel conforme à sa vision des règles appliquées et non conforme aux règles telles qu’elles sont inscrites. Du coup la réponse du logiciel paraît peu cohérente voire complètement fausse.

Comment l’éviter

Commençons par le plus important : le mode d’emploi de l’interface utilisateur n’est pas la solution pour éviter ce type de problème. Si je reprends l’exemple d’APB, tous les utilisateurs qui ne comprennent pas la décision finale ont comme argument : « mais je l’ai bien rempli pourtant », et c’est vrai. Le problème ici ne réside pas dans une mauvaise utilisation du logiciel mais dans une mauvaise compréhension du résultat de la bonne utilisation.

Les pistes pour éviter ce type de problème sont les suivantes :
 – Entretenir la confiance dans le logiciel : la première solution pour éviter les incompréhensions est que l’utilisateur ait un a priori positif sur la qualité de la réponse du logiciel. C’est pour cette raison que les premiers mois d’utilisation d’une application métier sont décisifs : ils construisent sa réputation. Si celle ci est mauvaise, et même si au final le logiciel fonctionne, les retours négatifs vont se multiplier car les utilisateurs vont croire que le retour étrange est tout simplement un bug.
Expliciter les décisions : quand un logiciel propose une résultat qui nécessite plusieurs étapes de calcul, il n’est pas déraisonnable de les expliciter en quelques phrases. Dans 90% des cas, l’utilisateur ne va pas lire ce petit résumé, mais celui-ci sera primordial dans les 10% restants. Un bon exemple dans le grand public est l’application web de saisie de la feuille d’imposition, qui propose en quelques lignes une explication du montant de l’impôt sur le revenu final.
Rendre l’interface de saisie la plus proche possible du processus de décision de l’ordinateur : par exemple, si les conditions de décision dépendent de l’état du dossier dans un cycle, il est préférable que soit présents à l’écran l’état de l’objet, le cycle et la position de l’objet dans le cycle. Le but est de donner à l’utilisateur la possibilité d’apprécier la situation en un coup d’oeil et d’éviter les qui pro quo.
Décrire dans une documentation les workflow de façon synthétique, et valider que cette documentation est précisément ce qui est appliqué dans le logiciel, et surtout la mettre à jour au fur et à mesure. Il m’est arrivé plusieurs fois d’avoir des rapports d’erreur concernant des calculs, et l’utilisateur qui écrivait le rapport d’erreur utilisait comme référence un tableur excel qu’il avait fabriqué pour l’occasion, mais sans l’avoir maintenu : un beau dialogue de sourds !
Créer un forum utilisateur : l’avantage de cette solution est qu’elle présente des cas pratiques. Mais c’est une arme à double tranchant : il est impératif que le forum soit modéré et validé par quelqu’un qui maîtrise les processus décrits dans l’étape ci-dessus. Toute personne ayant consulté des forums sur internet sait que l’on peut trouver des mauvaises idées tout comme des bonnes.

La leçon à retenir de ce type de problème est que l’évolution d’une application pendant sa vie n’est pas uniquement interne : l’évolution de son environnement et de ses utilisateurs fait partie intégrante de son cycle de vie et doit être prise en compte dès le départ dans sa conception. Cette phase est souvent oubliée, et cet oubli se paye des mois voire des années après l’écriture de la première ligne de code. Encore une bonne raison de placer l’utilisateur au centre du système d’information!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>