Articuler l'ordinateur et l'être humain

22 novembre 2003

Pour concrétiser le propos, nous allons considérer quelques exemples :

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. Mais 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 d'interpréter les cas particuliers en utilisant son discernement et son jugement. L'ordinateur traitera les cas simples, qui constituent la majorité des affaires ; son programme sera plus simple, donc moins coûteux, plus évolutif, mieux maîtrisable.

Il se produit des catastrophes lorsque le système d'information est conçu de telle 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 saurez ce que vous voulez faire il faudra 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 ce sera 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 vous faudra quelques années pour transformer l'entreprise. »
 

Certaines personnes répondent : « Vous proposez une démarche, mais 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é 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 bien sûr - IBM oriente ses clients vers la voie de l'échec, même si ce logiciel est excellent (IBM a d'excellents produits).

Les entreprises n’ont que trop tendance à croire que tout problème est technique (c'est-à-dire  qu'il relève é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 », sans quoi l'on commet 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 :

Exploitation d’une centrale nucléaire 

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 ». 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 imprévu se produit ils ne sauraient que faire. C'est pourquoi il est judicieux d'équiper une centrale nucléaire d'un logiciel moins complet qu'il ne serait techniquement possible.

Pilotage d’un avion

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.

Informatique de gestion

Considérons une administration comme les impôts, la sécurité sociale ou 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.

Systèmes experts

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, lui, é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.

Niveau optimal de la formalisation

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 ne contient pas d’information : il stocke et 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.