Articuler l'ordinateur et l'être humain

Une entreprise veut mettre sur son site Web la fonction d'intermédiation assurée jusqu'ici par une « première ligne » proche des clients et très expérimentée. Le client déposera sa demande, les fournisseurs leurs offres, l'informatique fera le rapprochement entre les deux. Il faut mettre l’entreprise en garde. Que va-t-il se passer si elle confie l'intermédiation à un automate ? Ne va-t-elle pas y perdre en efficacité ?

On sait qu'un logiciel de traduction automatique est (1) coûteux à concevoir, (2) fécond en contresens insupportables à la lecture, (3) moins efficace qu'un logiciel de traduction assistée par ordinateur dont la production coûte mille fois moins cher. Si vous souhaitez que l'ordinateur fasse tout, vous devez réaliser un programme qui saura traiter tous les cas particuliers ; il sera d'une complexité monstrueuse, et en fait il ne parviendra pas à traiter tous les cas particuliers. Si vous articulez l'ordinateur et l'être humain, vous pouvez laisser à ce dernier le soin de comprendre les cas particuliers avec son discernement et son jugement. L'ordinateur traitera les cas simples, qui constituent la majorité des affaires ; son programme sera également simple, donc moins coûteux, évolutif, maîtrisable.

Articulation entre l’ordinateur et l’être humain dans la relation avec les clients

Voici une anecdote authentique et significative :

Une entreprise a changé de banque en février 2001. Elle avait reçu à la fin 2000 un avis de la caisse de retraite indiquant les montants qui seraient prélevés chaque mois en 2001. Le comptable téléphone en février 2001 pour informer la caisse de retraite du changement de banque. Réponse : « Payez par chèque à l'échéance, nous vous envoyons une demande de prélèvement et vous pourrez indiquer votre nouveau compte. » Il envoie régulièrement les chèques mais ne reçoit aucun formulaire.

Par contre il reçoit en mai 2001 une mise en demeure comportant une importante majoration pour retard. Au téléphone, il tombe sur une personne qui ne comprend pas ce qui se passe (bien souvent, les entreprises n’accordent pas assez d’attention à la qualité de leur centre d’appel). Il se rend sur place. Les personnes de l'accueil, gênées, lui expliquent que rien ne permet d'informer l'ordinateur des paiements effectués par chèque. Donc l'automate a fait son travail : comme il ne perçoit pas les prélèvements, il en déduit que la cotisation n’a pas été payée, calcule les majorations et émet les mises en demeure.

Lors de la conversation, il s'avère qu'il manque deux francs sur l'un des versements mensuels. De plus en plus gênées, les personnes de l'accueil disent : « Nous ne pouvons pas percevoir d'argent liquide ; allez déposer les deux francs à la banque d'à côté et demandez un reçu que vous nous rapporterez ». Ainsi fut fait.

Il se produit des catastrophes lorsque le système d'information est conçu de sorte que les personnes de la première ligne n’aient pas la possibilité d'agir alors qu'elles ont expérience et bon sens et comprennent correctement chaque cas particulier. Il est impossible d'imaginer à l'avance la gamme des incidents qui peuvent survenir en cas d'automatisation, mais il est certain que des incidents se produiront. L'absurdité peut se déployer sans limites si on ne ménage pas la possibilité d'une « reprise de main » par un être humain.

Il est vrai que l'articulation entre l'automate et l'être humain demande des consultations, de la réflexion, bref une démarche délicate. On peut par exemple dire ceci à une entreprise désireuse de mettre en place l’e-business :

Démarche de mise en place de l’e-business

« Il ne suffit pas pour votre entreprise d'avoir une présence sur le Web, fût-elle jolie. Il faut d'abord connaître vos clients et savoir ce qu'ils attendent de vous, car le Web, c'est le pouvoir au client : si vous ne répondez pas comme il le souhaite, clic ! il est parti, vous pouvez lui dire adieu.

« Quel positionnement voulez-vous donner à votre entreprise sur le Web? jusqu'où voulez-vous pousser la différenciation de votre offre ? avec quels partenaires voulez-vous vous associer ? quelles relations souhaitez-vous avoir avec vos fournisseurs ? jusqu'où entendez-vous pousser l'intégration entre vos affaires et celles de vos partenaires, fournisseurs et clients ? Il faut ici une ingénierie d'affaire, avec ses dimensions juridique et financière. Souhaitez vous conserver la même périphérie, ou pensez vous qu'il faut externaliser certaines de vos activités ? Le e-business va de pair avec un e-management : il s'agit de penser la personnalité, les priorités, les contours de l'entreprise. Il convient que cette réflexion ne soit pas seulement celle du PDG, mais qu'elle soit partagée par les managers, les cadres et finalement toute l'entreprise, ce qui suppose consultations, concertations et validations.

« Enfin quand vous savez ce que vous voulez faire il faut s'assurer que c'est faisable. Vos limites sont ici celles de votre système d'information. Si celui-ci est constitué d'une accumulation d'applications hétéroclites fondées sur des définitions incohérentes, si les données de référence ne sont pas gérées, s'il n'existe pas de gestion de configuration, bref si vous n'avez pas une architecture de système d'information digne de ce nom, vous aurez du mal à jouer la partie de l'e-business. Ce ne sera pas totalement impossible – il n’est pas indispensable de passer par un ERP[1] avant de se lancer sur l'Internet - mais difficile. Le calendrier des fonctionnalités e-business sera articulé avec la remise à niveau de votre système d'information. Vous pouvez démarrer tout de suite, mais il faudra quelques années pour transformer l'entreprise. »

Mais certaines personnes répondent : « Vous proposez une démarche, ce qu'il nous faut c'est un produit ». Les fournisseurs de logiciels portent une part de responsabilité dans cette erreur de perspective. On a vu, sur la couverture du « Monde Informatique » n° 839 du 4 février 2000, la photo d'un fromager accompagnée de cette légende : « De quoi avez-vous besoin pour transformer votre business en e-business ? Découvrez-le page 11 ». Et à la page 11 on trouvait une publicité pour IBM contenant ces mots : « Il faut un puissant logiciel pour transformer le business en e-business. Ce logiciel existe, IBM l'a fait » Or la première question qu'une entreprise doit se poser n'est pas « quel logiciel choisir », mais « que veulent mes clients », puis « quel rôle dois-je jouer » etc. La check-list ne commence pas par la technique mais par la stratégie. En suggérant qu'il suffit de prendre un logiciel - le sien - IBM montre à ses clients la voie de l'échec, même si ce logiciel est excellent (ce qui est fort possible car IBM a d'excellents produits).

Les entreprises n’ont que trop tendance à croire que tout problème est technique (c'est-à-dire relevant étymologiquement du « savoir-faire »), et donc que toute solution doit être également technique. Mais avant de savoir faire, il faut savoir ce que l'on veut faire, pour quoi et pour qui on veut le faire. « Pourquoi faire » et « vouloir faire » doivent précéder « savoir faire » si l'on ne veut pas commettre de grossières erreurs. Dire cela, ce n’est pas dénigrer la technique mais la respecter assez pour ne pas l'utiliser à contre-temps.

Les systèmes d’information ne sont pas des automates dont on attend qu’ils règlent tous les problèmes, mais des outils destinés à assister des opérateurs humains. La conception du système d’information doit donc considérer non le seul automate, mais le couple formé par l’automate et l’être humain qu’il assiste. Ce dernier est d’ailleurs un être humain organisé (plusieurs spécialités coopèrent en général dans un même processus de production).

Le semi-désordre

Si le système d’information est trop « parfait » l’être humain peut devenir inefficace. Voici quelques exemples :

Les défaut du système d’information obligent les opérateurs humains à faire chaque jour des interventions manuelles pour corriger les données. Le jour où se produit un incident, ils savent comment faire car ils ont l'habitude de traiter les « pépins » informatiques. Si le système d’information était parfait, les opérateurs perdraient l'habitude de réagir, feraient confiance au système, et quand un incident se produit ils ne sauraient que faire.

La conception des avions est l’enjeu d’un conflit entre ingénieurs et pilotes. La qualité des avions étant élevée, les ingénieurs voient dans le « facteur humain » la cause résiduelle des accidents. Pour l’éliminer ils souhaitent concevoir l'avion « parfait » qui décollerait, volerait et se poserait sans pilote. Cependant les pilotes disent qu’il reste des situations où l'on a besoin du cerveau humain pour synthétiser, arbitrer et décider : l’avion doit certes comporter des automatismes, mais ceux-ci doivent assister le pilote et non le supplanter.

Considérons une administration comme les impôts, la sécurité sociale ou encore l'ANPE. La réglementation évolue souvent, ce qui exige de modifier le système d’information. La modification est simple s’il s’agit de mettre à jour quelques paramètres, elle est complexe s’il faut redéfinir une partie d’un dossier et introduire des traitements nouveaux. Il faut de trois à six mois pour introduire une modification complexe dans le système d’information. Si celui-ci est de qualité médiocre, il faudra un an pour corriger les bugs provoquées par la modification. Pendant ce délai la réglementation aura encore changé.

Les agents se sont donc habitués à faire une partie de leur travail sur papier ou sur tableur, puis à saisir les données dans le système d’information. Cela comporte des inconvénients (erreurs de calcul ou de saisie, surcharge de travail, inefficacités diverses etc.), mais ce fonctionnement d'ensemble permet à l’administration d’être réactive et de mettre en oeuvre sans délai une politique nouvelle.

On a pu, dans certaines entreprises, modéliser la pratique professionnelle des agents pour automatiser leur démarche et gagner en rapidité. C’est ainsi que les banques ont conçu des systèmes experts de gestion de trésorerie. Cependant, si le contexte évolue, le système expert ne saura pas évoluer et il perdra en efficacité alors qu’un opérateur humain aurait adapté ses méthodes de travail et modifié ses « règles de pouce ». Il faut donc conserver, à côté du système expert qui fera le gros du travail, des opérateurs humains plus lents sans doute, mais dont le savoir pourra être périodiquement réinjecté dans le système expert pour le mettre à jour.

La gestion d’un système d’information (ou d’un projet) navigue entre deux extrêmes. Suivre une méthodologie oblige à consacrer beaucoup de temps à la production de documents qui décrivent le système d’information sans faire nécessairement progresser son adéquation fonctionnelle. On peut aussi pratiquer l'artisanat « à l'ancienne » : dès qu’un métier a besoin de quelque chose, il demande aux informaticiens de le développer ; il revient à ceux-ci de gérer l'intendance, le métier ne se souciant pas des problèmes « techniques » du système d’information.

Si l’on tolère la non-formalisation, les maîtrises d’ouvrage risquent de s’y engouffrer ; si on exige une formalisation complète, l’entreprise s’enlisera dans la production de documents en grande partie superflus. Le moyen terme efficace résulte du bon sens qui ne peut se formaliser entièrement.

Un système d’information totalement désordonné n’est pas un système (la notion de système implique la cohérence) et il ne contient pas d’information : il produit des données qu’il est impossible de comparer et donc d’interpréter. Le désordre, c’est la mort du système d’information.

La perfection serait une autre forme de mort : elle démobilise les opérateurs humains. De même, l’entreprise qui veut se doter d’un référentiel « détaillé » échouera si elle ne fixe pas de borne à l’exigence du détail. Le mieux est ici l’ennemi du bien. Il faut admettre une dose de « non qualité » (apparente) pour que la coopération entre l’automate et l’être humain soit convenable.

Le laxisme se présente sous deux formes : la raideur méthodologique qui aboutit soit à la mort du système d’information soit (conséquence moins dommageable) à la frustration du méthodologue qui ne parvient pas à se faire entendre ; le fatalisme, que traduisent l’expression « ça finira par tomber en marche » ou la fameuse phrase attribuée au président Queuille (1884-1970) : « il n’existe pas de problème dont une absence persévérante de solution ne finisse par venir à bout ».

Le semi-désordre est à l’opposé du laxisme : celui qui perçoit la façon dont l’automate et l’être humain organisé s’articulent ne surestime pas les apports du formalisme et ne s’en remet pas au fatalisme. La conception claire du résultat opérationnel à atteindre guide le choix de ses priorités et l’aide à définir les simplifications nécessaires.

[1] « Enterprise resource planning »