Blog

Informatisation des processus et facteur humain

Thierry Chatel • 6 septembre 2011

Informatiser une tâche ou un processus administratif, dans une entreprise ou toute autre collectivité, n'est pas sans conséquence sur le travail des employés qui en sont chargés. Il est important de bien comprendre les enjeux et les impacts que cela implique.

Adaptation et autocorrection

Commençons par examiner un processus non informatisé. Un tel processus peut être n'importe quelle tâche administrative dans une entreprise, une collectivité, une association, comme par exemple l'embauche d'un nouveau salarié, la gestion des stocks, le traitement de commandes, de réclamations, etc. Les exemples sont nombreux, et de plus en plus les entreprises ou collectivités concernées se dotent, quand elles en ont les moyens, d'outils informatiques spécifiques pour gérer de telles tâches.

Prenons le cas d'un processus qui n'est pas géré via un logiciel spécialisé, donc effectué uniquement sur dossier papier ou avec l'usage du mail ou d'outils bureautiques. Ce processus n'est pas contraint par un quelconque logiciel, ce sont les gestionnaires qui l'ont en charge qui connaissent la démarche à appliquer.

Ces mêmes gestionnaires en charge d'appliquer la démarche prévue sont capables d'en sortir lorsque des cas inhabituels se présentent. Ils peuvent adapter leur travail à des changements dans le contexte de leur tâche, par exemple dans la réglementation en vigueur, ou simplement pour gérer plus efficacement le processus en question, grâce à leur expérience. C'est un phénomène d'apprentissage et d'adaptation, naturel pour des humains, mais dont un logiciel est incapable.

Un tel processus non informatisé est naturellement autocorrectif. Les gestionnaires qui l'ont en charge savent trouver des solutions en cas de problème ou d'anomalie, quitte à sortir de la démarche normale, parce qu'ils ont une connaissance du but à atteindre. Ils sont capables de voir dans certaines situations sortant du cadre défini pour ce processus que la démarche standard ne permettra pas d'atteindre le but recherché.

Déterminisme et frustration

Bien sûr, les avancées en intelligence artificielle sont bien insuffisantes pour nous permettre d'imaginer un jour où les ordinateurs seront conscients du but à atteindre et capables d'adapter la démarche pour y parvenir aux particularités de chaque cas inhabituel.

C'est l'impact majeur lié à l'informatisation d'un processus : ça le rend déterministe. Le processus informatisé n'a plus de capacité d'adaptation ni d'autocorrection.

Si une procédure administrative est gérée avec une application spécialisée, que ce soit un logiciel du commerce ou une application développée spécifiquement pour l'entreprise ou la collectivité utilisatrice, alors la démarche ne pourra plus sortir des options prévues et implémentées en dur dans le logiciel.

Le fait d'informatiser des processus n'est pas une mauvaise chose en soi, au contraire, et si cette tendance existe ce n'est pas sans raison : ça permet une gestion plus rigoureuse, plus efficace, plus contrôlable. On a besoin pour pouvoir faire un suivi ou des statistiques d'organiser les données d'un processus selon un schéma suffisamment strict, et par exemple de les stocker dans une base de données relationnelle. C'est cette rigueur nécessaire qui va permettre l'exploitation de ces données, alors qu'on ne sait pas exploiter des échanges de mails. Mais on perd au passage la souplesse et la capacité d'autocorrection d'un processus non informatisé.

Cet aspect peut même être très frustrant pour les gestionnaires, lorsqu'ils savent ce qu'il faudrait faire pour traiter un cas particulier, et qu'un logiciel trop rigide les en empêche. "Je n'y peux rien c'est l'ordinateur !", la phrase est presque devenue le refrain de nos administrations. Le logiciel trop souvent ne permet plus de faire ce que n'importe quel utilisateur sait qu'il faudrait faire dans un cas donné. On comprend aisément la frustration des gestionnaires régulièrement confrontés à ce manque de souplesse qui les empêche d'effectuer correctement leur travail, et la perte de motivation qu'elle peut entraîner.

Logiciels moins déterministes

Comment conserver au moins une partie de ces capacités d'autocorrection lors de l'informatisation d'un processus ? La première façon, qui est la plus évidente et la plus pratiquée, c'est de faire évoluer le logiciel en fonction des retours de ses utilisateurs. Ceci s'applique bien entendu au cas où il s'agit d'un logiciel développé spécifiquement, mais même dans le cas de l'achat d'un logiciel du commerce, il peut y avoir un peu de marge de manœuvre dans les possibilités de paramétrage pour tenter d'atténuer les problèmes signalés.

Il faut toujours prévoir après la mise en production d'un logiciel spécifique une phase de maintenance évolutive. Même si une démarche itérative a été employée pour le développement, et que les utilisateurs ont pu manipuler et tester l'application avant sa mise en production, il y a toujours des surprises, et en la confrontant aux cas réels à traiter on en découvre forcément qui posent problème, des situations inhabituelles que l'application ne permet pas de gérer correctement. Il faut demander explicitement la participation des utilisateurs du logiciel à cette phase d'amélioration, recueillir leurs retours et les prendre en compte pour faire évoluer rapidement le logiciel. Il y a évidemment un aspect psychologique important, et le fait d'impliquer davantage les utilisateurs et de leur permettre d'améliorer l'outil est bien plus gratifiant que d'être passifs et frustrés face aux contraintes et aux difficultés qu'il impose à leur travail. Mais le bénéfice sur le logiciel lui-même est réel. En profitant de l'expérience concrète de ses utilisateurs, les capacités de prise en compte des cas difficiles par le logiciel seront nettement améliorées, et il permettra ainsi une meilleure gestion du processus et une plus grande efficacité. Ainsi l'absence de capacité d'autocorrection intrinsèque au logiciel est compensée partiellement par l'expérience des gestionnaires qui l'utilisent si leurs retours sont pris en compte pour faire évoluer le logiciel de façon externe.

Il est possible aussi de limiter le déterminisme qu'impose le logiciel au processus, ou au moins prévoir un minimum de souplesse dans le logiciel. L'ergonomie déjà devrait permettre les retours en arrière et faciliter les corrections d'erreurs, aspects importants mais trop souvent négligés dans la conception des applications de gestion, ce qui peut faire regretter la souplesse du travail sur papier. L'interface utilisateur peut aussi donner la possibilité au gestionnaire de mettre un commentaire libre sur un dossier à traiter, pour lui-même afin de se rappeler de quelque chose, ou à destination d'un autre gestionnaire. On ne peut pas dans une application informatique coller un Post-it ou ajouter une feuille volante comme on le ferait avec un dossier papier, pour noter quelque spécificité du traitement de ce dossier ; si l'application offre une possibilité de ce type, elle sera plus facilement utilisable par les gestionnaires qui pourront ainsi associer librement des informations annexes importantes, en complément des données organisées gérées dans le dossier informatique.

L'interface du logiciel informatisant un processus administratif peut aussi présenter des zones de wiki alimentées ou modifiées par les gestionnaires, pour capitaliser sur leur connaissance du traitement du processus en question. Le contenu de ces zones de wiki ne fera pas partie des données des dossiers à traiter, mais bien de l'interface utilisateur elle-même. Il s'agit en fait de remplacer un texte d'explication, comme on peut en trouver dans bien des formulaires papier, par une zone dont le contenu peut être modifié si nécessaire par les gestionnaires eux-mêmes, par exemple pour signaler un changement de réglementation ayant un impact sur les données à saisir, ou encore une difficulté temporaire dans le traitement de certains types de dossiers. De cette façon les gestionnaires peuvent s'approprier le logiciel, et y introduire leur connaissance de la gestion du processus.

Mais au-delà de l'interface utilisateur, au niveau du cœur même du logiciel, dans la gestion du processus, les règles métier peuvent être implémentées de façon souple, sous la forme de suggestions plutôt que de règles strictes, en laissant au gestionnaire le choix final dans la manière de traiter chaque dossier. Imaginons que le traitement d'un dossier implique un certain nombre d'étapes, mais pas toujours les mêmes, certaines étapes n'étant nécessaires qu'en fonction des données du dossier. Un logiciel strictement déterministe contiendra des règles figées déterminant quelles étapes sont nécessaires en fonction du contenu du dossier. Mais on peut préférer une approche où après la saisie du dossier, le logiciel propose à partir des mêmes règles la liste d'étapes du traitement, mais laisse au gestionnaire la possibilité de la modifier, d'enlever une étape dont il sait qu'elle est inutile, ou d'en ajouter une dont l'utilité n'a pas été décelée par le programme. Cette seconde approche n'ajoute pas de travail supplémentaire au gestionnaire, car dans la plupart des cas il validera la liste d'étapes proposée sans y apporter de modifications, mais elle lui permet d'utiliser son expérience du métier pour adapter la façon de traiter des dossiers inhabituels pour lesquels la démarche standard n'est pas appropriée.

Conclusion

Il est important de tenir compte du facteur humain dès la conception d'un logiciel de gestion destiné à informatiser un processus. Le logiciel est là pour fournir un cadre de travail structuré et efficace, pas pour se substituer à l'expérience des gestionnaires en voulant la remplacer par un ensemble de règles souvent trop schématiques et qui ne pourront pas gérer tous les cas particuliers.

Il faut tenir compte des retours des utilisateurs pour améliorer le logiciel, en prévoyant dès le début du projet une phase d'évolution après la mise en production, et rendre le logiciel suffisamment flexible pour que les gestionnaires puissent adapter son comportement dans les situations où ils savent que celui prévu par défaut ne sera pas adéquat. C'est tout ce qui fera la différence entre un logiciel bien ou mal conçu, entre un outil qui simplifiera le travail et un autre qui le rendra pénible.

Derniers billets

11 juin 2012

Avenir des applications web RIA

Ou la percée des frameworks clients JavaScript dans le développement d'applications web.

5 avril 2012

Exemples d'utilisation du framework AngularJS

Voici les fichiers des exemples que j'ai montrés lors de ma présentation du framework AngularJS à Montpellier.

15 mars 2012

AngularJS, énième framework JavaScript ou pierre angulaire des applications web ?

Un nouveau framework qui révolutionne l'écriture de clients web, et destiné à connaître un gros succès.

6 septembre 2011

Informatisation des processus et facteur humain

Ou quels sont les inconvénients du déterminisme induit par l'informatisation, et comment les éviter au maximum ?

26 août 2011

Ergonomie des applications web et productivité

Quelles fonctionnalités plus ou moins courantes sur internet peuvent être adoptées avec succès dans des applications de gestion, pour permettre un travail plus efficace ?

11 août 2011

Réutilisation et recyclage

Que peut-on apprendre de la navette spatiale américaine à propos de la réutilisation de code en informatique ?

Flux

Atom