Entretien avec J-R. Ruault ; Ergonomie et BPM : quelles complémentarités ?

Introduction

Un des objectifs central du métier de l’ergonome est de comprendre le travail pour le transformer, afin de l’adapter à la logique des utilisateurs. Quel que soit son domaine d’activité, et afin de mener à bien cette mission, l’ergonome va devoir comprendre le contexte dans lequel l’utilisateur évolue, quelles sont les grandes règles de fonctionnement, quels sont les processus qui conditionnent ce qu’il fait. Le métier d’analyste BPM (modélisation des processus métier) a également pour objet d’étude ces processus . Il nous semblait donc fort intéressant de consacrer un entretien décrivant les frontières entre ergonomie et BPM.

Jean-René Ruault, expert en ingénierie système, a accepté de partager son expérience sur le sujet dans un regard croisé entre ergonomie et BPM.

Encore merci pour sa disponibilité !

La fiche de Jean-René Ruault


Photo-RuaultExpert méthodes et outils d’ingénierie système, DGA, Paris

Formation : DEA en psychologie sociale expérimentale, EHESS et formation complémentaire en informatique industrielle.

Expérience professionnelle : Après plus de dix ans dans des sociétés de service, il rejoint la DGA en 2004, où il exerce maintenant une activité d’ingénierie des systèmes.

Il est co-animateur du comité technique consacré aux systèmes de systèmes et aux services, au sein de l’AFIS. Il a publié plusieurs articles dans le domaine de l’ingénierie des systèmes et des interactions homme-machine. Il a été coprésident de la conférence Ergo’IA  2006. Dominique Luzeaux et lui ont publié plusieurs ouvrages consacrés à l’ingénierie système et aux systèmes de systèmes (SdS), en français (Hermès) et en anglais (Wiley).

Début de l’entretien

Bonjour M. Ruault et merci d’avoir accepté de partager autour de l’ergonomie et du BPM. Pouvez-vous décrire succinctement la notion de « BPM » à nos lecteurs. Faire un bref état des lieux ?

Bonjour, merci pour cet entretien. Le BPM, Business Process Modeling, signifie modélisation des processus ou activités métier. Cette discipline vise à rendre compte, formaliser et spécifier les activités à mettre en œuvre dans un domaine afin de les automatiser. C’est un concept bien connu dans le domaine des systèmes d’information et celui de la qualité.

Lorsqu’un ergonome fait de la conception de système, il est amené à faire en amont une analyse de la tâche. Cette analyse de la tâche s’inscrit dans un contexte organisationnel. L’ergonome est donc amené à faire une analyse des processus associés à la tâche de l’utilisateur. Cela semble fort lié au BPM.

Vous avez tout à fait raison. C’est un sujet à double tranchant et paradoxale.

(…)

Historiquement, l’objet du BPM est d’élaborer un flux d’activité (workflow) automatisé. Les normes traitant de BPMN, que je présente dans notre ouvrage (Jean-René Ruault, 2008), sont tout à fait explicites à ce sujet. Elles ont la faculté de traduire directement un processus métier en code.

(…)

Ensuite, une grande caractéristique du BPM est d’être indépendant du contexte. Les tentatives de type Praxème© apportent bien un peu de contexte, mais de façon très limitée et toujours dans une perspective a priori. Rien, dans le BPM, ne permet de prendre en compte les aléas d’une situation, c’est-à-dire ce qui n’est pas prévu.

(…)

Ainsi, l’objet d’étude entre BPM et ergonomie est fort similaire, mais la perspective pour l’appréhender est tout à fait différente.

Mais pourtant, historiquement, le domaine des systèmes d’information doit bien considérer l’utilisateur non ?

Très peu. La démarche, réductionniste, ne prend pas en compte et ne permet de rendre compte ce qui caractérise l’humain… son comportement, ses intentions, ses objectifs, la confiance qu’il a dans les machines… sa compréhension de la situation, du contexte, etc.

(…)

Cela transparaît dans la littérature relative aux systèmes d’information. Rien sur l’intentionnalité des acteurs humains, dans une logique à la Crozier, rien sur la dimension paradoxale des communications et des comportements de ces acteurs (Watzlawick). L’adaptation, l’appropriation du dispositif technique par les opérateurs humains sont tout à fait ignorés. Nous ne trouvons rien sur l’engagement personnel de l’acteur dans la réalisation de son activité, ni sur le développement personnel et professionnel.

Donc, le fait que l’ergonome envisage l’analyse des processus organisationnels du point de vue du facteur humain, en considérant l’opérateur, son profil, sa tâche, le tout dans un contexte d’utilisation ouvre la brèche à une collaboration intéressante entre BPM et ergonomie

Tout à fait. Il y a une véritable carte à jouer pour l’ergonome. Il décrit l’activité réelle de l’être humain, en situation, de manière contextualisée et apporte des éléments complémentaires à l’analyse BPM.

(…)

Une approche commune permet, grâce à l’ergonome d’analyser en vue de concevoir un système technique qui soit adapté au métier des opérateurs humains, et grâce à la modélisation des processus métier (BPM) d’analyser le métier pour l’automatiser.

Au départ, le BPM semble très technique, confiné à un contexte très spécifique, un peu éloigné de l’ergonomie. Qu’en pensez-vous ?

Son application s’élargit petit à petit, en particulier avec la diffusion de plus en plus importante des cadres d’architecture (architecture framework).

Quel est le point de contact entre les deux disciplines ?

En mettant en perspective l’ergonomie et le BPM, nous retrouvons la ligne de fracture traditionnelle entre l’activité réelle et l’activité prescrite que connaissent bien les ergonomes. La notion d’activité réelle n’est pas du tout appréhendée par le BPM. Le fait de considérer le contexte, le fait de s’adapter face à des aléas qui ne peuvent pas être définis, anticipés, sont des capacités propres aux acteurs humains. Les systèmes d’information, basés sur des automatismes, ne peuvent présenter ces capacités.

(…)

C’est le point de contact entre les deux disciplines.

L’ingénieur doit tout de même bien être conscient de la différence entre activité réelle et activité prescrite

Du point de vue de l’ingénieur concepteur, tout écart entre la tâche prescrite et ce qui est réalisé relève de l’anomalie. Là encore, il n’y a pas de moyen pour rendre compte de la variabilité des comportements. Nous sommes face à un opérateur moyen, au sens statistique du terme, tout aussi improbable que la femme allemande qui aurait 1,37 enfants (Indicateurs de fécondité (nombre moyen d’enfants par femme, donnée INED 2008). Dans la mesure où il s’agit d’une activité future probable, nous devrions aussi disposer d’une pondération en termes de probabilité. Il n’en est rien. L’activité est supposée se dérouler sans cesse, ainsi qu’elle a été spécifiée.

Du point de vue d’un ergonome, il semble tout à fait aberrant d’appréhender les processus sans considérer l’être humain

Évidemment. L’article de René Amalberti illustre à merveille cela. Notamment à travers son étude sur les circuits des médicaments. L’automatisation des métiers, sans prendre en compte les activités réelles des opérateurs est une source d’erreur du système technique. Dans certains cas, cela peut avoir des conséquences extrêmement graves, avec la mort d’êtres humains.

Il est donc intéressant d’adopter une approche projet qui mixe BPM et ergonomie. Mais comment faire ?

L’article que j’ai soumis avec Eddie Soulier, Florie Bugeaud à ErgoIA 2008 essaie d’apporter quelques éléments de réponse.

(…)

Si je me permettais une métaphore, je dirais que l’activité prescrite est la partition d’une symphonie. Chaque performance, au sens anglais du terme, de la partition, est une interprétation singulière prenant en compte intimement le contexte. Par Furtwängler, Toscanini ou Karajan, la 9ième symphonie de Beethoven est à la fois toujours la même et toujours une autre. Avec un orgue de barbarie, ce sera toujours la même, en faisant abstraction de la déformation des cartes perforées, de façon lancinante.  L’interprétation de l’orgue de barbarie est indépendante du contexte. En revanche, sans partition commune, en absence d’une notation reconnue par tous les musiciens, comment plusieurs orchestres différents pourraient-ils collaborer, interpréter une œuvre en commun ? Nous serions obligés, à l’inverse de l’orgue de barbarie, d’écouter un bœuf permanent.

(…)

De mon point de vue, cette analogie peut être appliquée dans notre domaine.

Plus concrètement ?

Si le processus métier à traiter, à concevoir, est tendanciellement déterministe, avec des contextes finis et définis a priori, et n’est pas sensible, dans sa réalisation, aux aléas, nous pouvons envisager de l’automatiser et d’appliquer la démarche BPM, jusqu’à la production du code qui supporte le flux d’activité. Ce peut être le cas dans les systèmes de régulation ferroviaire fermés comme la ligne 14 du métro parisien.

(…)

Si le processus métier à traiter, à concevoir, est très interactif (voir Thompson et Perrow, dans Jean-René Ruault, « La place de l’humain dans le contexte des systèmes de systèmes »), fortement dépendant du contexte et présentant de nombreux aléas, il faut envisager le processus métier, la partition, comme structurant, mais devant laisser toute sa place à l’interprétation par l’opérateur humain pour prendre en compte le contexte et les aléas.

Les formalismes de modélisation métier de type « ARIS », « MEGA », ou autres, semblent tout à fait compatibles avec les formalismes classiques utilisés en ergonomie

Oui vous avez raison. D’ailleurs, à mon sens, maîtriser les formalismes BPM est un pré requis incontournable pour les ergonomes qui souhaitent s’investir dans l’analyse des processus métier. Des ergonomes, telle que Marie Catherine Beuscart-Zephir, utilisent les notations de la modélisation des processus métier. Cela permet, évidemment, de mieux communiquer avec les ingénieurs.

Y a-t-il déjà eu des tentatives de prise en compte des caractéristiques des utilisateurs dans le BPM ?

A ce que je sache, peu, voire pas du tout. Ce n’est par manque de méthode. Nous trouvons des liens étroits entre ergonomes et génie logiciel dans le domaine des IHM. Depuis 20 ans, il y eu de nombreux travaux sur ce sujet. J’y ai, pour ma part, contribué, avec plusieurs articles dans les années 90.

Est-ce que vous pensez que le BPM pourrait envisager l’utilisateur comme acteur du système, avec un environnement et des contraintes, un objectif, etc. ?

C’est une situation paradoxale. Pour de nombreux auteurs et praticiens du BPM, les acteurs humains font partie, sont des composants, des systèmes d’information. Puisque, pour eux, c’est une machine de Turing, et vu qu’il y a isomorphisme entre l’être humain et l’ordinateur, il n’y a pas de souci : l’humain est bien pris en compte, puisqu’il fait partie du système d’information.
Est-ce que le fait de considérer explicitement la notion de profil utilisateur dans les processus ne poserait pas de problèmes éthiques ?

Absolument pas. Il s’agit bien d’un profil utilisateur, anonyme. Il ne s’agit pas des caractéristiques de Madame Durand et de Monsieur Martin (et vice et versa). Bien au contraire, il faut bien un profil utilisateur pour protéger les informations personnelles. Un profil médecin a le droit d’accéder à des information médicales personnelles, accès interdit à un profil différent non médical.
Posons la question différemment : n’y a-t-il pas un risque à ce que la prise en compte explicite des profils utilisateurs dans l’analyse BPM nous amène à des déviances de la part de décideurs de type : « Pour ce poste, l’analyse nous démontre que pour améliorer la compétitivité il nous faut une femme, de 35 ans, blanche, qui n’a pas d’enfant ».

Tout peut être dévié, vous avez raison. Nous avons trois dimensions à traiter, celle de l’éthique, celle de l’air du temps et celle de l’ergonomie. En terme éthique, de mon point de vue, la réponse, face au risque de déviance, réside dans le droit et son application. A ce niveau, je suis plutôt intransigeant. En terme d’air du temps, ma position est clairement opposée à toute ségrégation, quel que soit son type. En terme d’ergonomie, pour moi, nous devons chercher à concevoir une activité et un poste de travail adaptés aux opérateurs, et identifier les caractéristiques des opérateurs structurantes pour la conception du système. L’excellent papier de Charles KIirke, que je synthétise dans le chapitre « « La place de l’humain dans le contexte des systèmes de systèmes », montre très bien ces aspects-là avec la féminisation de l’armée au Royaume Uni. Lorsque le poste de travail génère de fortes contraintes, il me semble judicieux de les identifier et de les tracer dans le profil de poste. Daltonien, je ne suis pas mécontent que cela ait été détecté il y a 30 ans et que l’on m’ait déconseillé une filière d’activité, l’électronique, dans lequel les couleurs jouent un rôle non négligeable.

Auriez-vous un article clé à proposer à nos lecteurs pour mieux comprendre le lien entre facteurs humains et ingénierie système ?

Sans prétendre faire le tour de la question, nous essayons, dans notre article (Jean-René Ruault, Christian Colas, Jean-Claude Sarron et Dominique Luzeaux,) ainsi que celui publié dans le JESA, de traduire cela dans les processus et activités aux confins des facteurs humains et de l’ingénierie système.  C’est une activité qui nécessite une contribution pluridisciplinaire.

M. Ruault, merci pour votre disponibilité et très bon vent dans la sphère de l’ingénierie système !

En savoir plus !

Amalberti R., Violations et migrations ordinaires dans les interactions avec les systèmes automatisés, Journal Européen des Systèmes Automatisés, VOL 43/6 – 2009 – pp.647-660

Bernonville S. & Beuscart-Zéphir M., Mise en œuvre d’un système d’aide aux choix des méthodes et modèles du GL et de l’IHM dans le cadre de  projets visant l’informatisation de processus complexes en milieu hospitalier. Proceedings of  IHM  2008,  20ème  Conférence  de  l’Association  Francophone  d’Interaction  Homme-Machine  (Metz,  France,  3-5  septembre  2008),  International  Conference  Proceedings Series, ACM Press, Metz, pp. 151-158, septembre, 2008

Beuscart-Zéphir M.C., Elkin P., Pelayo S. & Beuscart R., The Human Factors Engineering approach to biomedical informatics projects: state of the art,  results, benefits and challenges, Methods of Information in Medicine, IMIA Yearbook of  Medical Informatics special issue, pp. 159-177, 2007

Pariès, J., (2006), Complexity, emergence, resilience  in Hollnagel, E., Woods, D. & Levenson, N. (Eds), Resilience Engineering. Concepts and precepts. Hampshire, England : Ashgate

Ruault J.-R., « La place de l’humain dans le contexte des systèmes de systèmes »,  dans Dominique Luzeaux et Jean-René Ruault (sous la direction de), « Systèmes de systèmes ; concepts et illustrations pratiques »,  éditeur Hermès Science Lavoisier, 388 p, juin 2008, Ruault J.-R. & Meinadier J.-P., « Normalisation dans le domaine de l’ingénierie des systèmes et des systèmes de systèmes », , dans Dominique Luzeaux et Jean-René Ruault (sous la direction de), « Ingénierie des systèmes de systèmes ; méthodes normes et outils », éditeur Hermès Science Lavoisier, juin 2008

Ruault J.-R., Adaptabilité des systèmes à logiciel prépondérant. Appropriation et démarche orientée « aspect », Journal Européen des Systèmes Automatisés, VOL 43/6 – 2009 – pp.683-710

Ruault J.-R., Colas C., Sarron J.-C. & Luzeaux D.,« Ingénierie système et résilience des systèmes sociotechniques »,  5ème Conférence Annuelle d’Ingénierie Système AFIS 2009 Soulier E., Bugeaud F. & Ruault J.-R., « Nouveaux concepts pour la collaboration entre experts des facteurs humains et ingénieurs des systèmes », Ergo’IA 2008, Biarritz, octobre 2008