Des vieilles applications aux nouveaux processus

(Contribution à l'ouvrage de Jean Rohmer, Des tabulatrices aux tablettes, CIGREF et Nuvis, 2014.)

Introduction

L'informatisation s'est longtemps focalisée sur les « applications », programmes informatiques qui s'appuient sur la définition des données et sur des algorithmes. L'« approche par les processus », qui embrasse à la fois l'informatisation et l'organisation du travail humain, s'est imposée progressivement dans les années 1990.

Elle concrétise un alliage du cerveau humain et de l'automate qui fait émerger progressivement une économie et même une société nouvelles. Les entreprises commettent beaucoup d'erreurs mais, contrairement aux politiques, elles ne peuvent pas échapper longtemps à la pression physique de la nécessité. Elles constituent donc le laboratoire dans lequel cet alliage pourra par tâtonnement trouver sa pleine efficacité – mais il n'est pas sûr que cela se passera en France.

Application et processus

Une « application », c'est un programme qui reçoit des données (saisies manuellement ou provenant d'autres applications) puis leur applique un traitement pour fournir des résultats. Ainsi un programme de paie, convenablement alimenté, fournit des feuilles de paie, un programme de comptabilité fournit des comptes à jour. Les outils du travail personnel (traitement de texte, tableur) sont eux aussi des applications.

Le mot « processus » résume l'expression « processus de production » : il désigne l'ensemble des opérations qui, dans une entreprise, permettent d'élaborer un produit à partir de matières premières ou produits semi-finis.

À tout produit correspond le processus qui permet de le produire. Les processus existent donc depuis le néolithique et le concept n'a rien de nouveau. Cependant un processus peut être plus ou moins bien organisé. S'il est gouverné par des habitudes et traditions implicites son efficacité sera presque toujours médiocre : délais et qualité aléatoires, tâches redondantes, bras morts où s'égarent des travaux inachevés, etc.

La modélisation d'un processus explicite et organise la succession des activités qui contribuent à l'élaboration du produit. Elle permet aussi de contrôler qualité et délais.

L'informatique s'est focalisée au début des années 60 sur des opérations gourmandes en temps et en paperasses : comptabilité, paie, facturation, gestion des stocks, prise de commande. Elle s'est ainsi résumée à quelques grandes applications auxquelles l'entreprise attribuait un nom propre : Frégate à France Telecom, Sabre et Amadeus dans le transport aérien.

L'attention des informaticiens s'est naturellement concentrée sur les algorithmes qui procurent un résultat à partir des données saisies. Mais il est bientôt apparu qu'une même saisie devait pouvoir nourrir plusieurs applications, que le résultat d'une application devait pouvoir en alimenter une autre : la normalisation des bases de données et l'architecture des systèmes d'information ont dans les années 70 répondu à l'exigence de cohérence qui en résultait.

Dans les années 80 la dissémination des micro-ordinateurs et des réseaux locaux – puis dans les années 90 celle de l'Internet – a fait franchir un pas supplémentaire. Avec la documentation électronique et la messagerie il devenait en effet possible d'informatiser le parcours d'un processus en transférant d'un poste de travail au suivant les documents où s'inscrit l'élaboration du produit. À chacune de ces étapes l'informatique a dû s'enrichir de spécialités nouvelles tandis que des spécialités auparavant prestigieuses étaient repoussées au second rang : cela ne s'est passé ni sans drames, ni sans conflits.

Nota Bene : on peut représenter cette évolution par un petit modèle en couches : les données forment la couche 1, les algorithmes la couche 2, les applications sont le service rendu par l'empilage des couches 1 et 2¹ et les processus forment la couche 3. Historiquement ces trois couches ont été abordées dans l'ordre 2 – 1 – 3.

L'approche par les processus

Pour les informaticiens l'émergence des processus ne supprime évidemment pas les applications : il sera toujours utile de transformer automatiquement des données en résultats. Mais le point focal de leur attention s'est déplacé et cela a eu des conséquences.

Comme tout processus est orienté vers le produit qu'il élabore, il est naturel de lui associer le nom et l'image de ce produit. La personnalité des outils que sont les applications (Frégate, Amadeus, etc.) s'estompe alors dans l'entreprise pour faire place à celle des produits, biens ou services auxquels sont associés des attributs de qualité (téléphone « intelligent », voyage « de bout en bout » etc.). Il en résulte une transformation du rôle de l'informatique.

Jacques Mélèse avait introduit opportunément au début des années 70 la notion d'un système d'information s'ajoutant aux systèmes de gestion et de production. Cela a aidé les dirigeants à prendre conscience du rôle de l'informatique, et les informaticiens à prendre conscience des exigences de la cohérence des données.

Mais avec l'approche de l'entreprise par les processus l'informatique n'apparaît plus comme un système qui s'ajoute aux deux autres : elle s'insinue dans l'intimité de la gestion et de la production dont elle devient inséparable. Formaliser un processus conduit en effet à l’équiper d’une documentation explicite des tâches et de leurs relations. Il s'agit de :

• préciser les interfaces nécessaires à chaque activité (on regroupe sur le même écran les plages de consultation et de saisie, ce qui évite à l'agent la connexion à d’autres applications ainsi que la navigation dans des codes et touches de fonction diverses) ;
• programmer les tables d’adressage permettant de router automatiquement les messages à l’issue d’une tâche (à la fin de son travail l’utilisateur n’a pas à chercher à qui il doit en envoyer le résultat : il clique seulement sur le bouton « valider ») ;
• surveiller le délai de réalisation d’une tâche par un timer (horloge) qui prévient l’utilisateur en cas de dépassement ou qui ré-expédie le message vers un autre utilisateur².

Modéliser un processus, c’est décrire la succession des tâches qui concourent à une production : le modèle décrit ce que fait chaque acteur, les données qu’il manipule, les traitements qu’il ordonne, les délais dans lesquels son travail doit être exécuté, le routage de ses messages vers les autres acteurs, les compteurs de délai et de volume qui permettent au superviseur de contrôler la qualité.

Si la réalisation des tâches est documentée par le modèle, leur accomplissement effectif nécessite une action qui ne peut être réalisée que par un être humain et échappe donc à l’ordinateur même si celui-ci aide sa préparation. Le workflow aide l'agent sans se substituer à lui en automatisant des tâches répétitives que l’on faisait auparavant à la main (un workflow, ou « flux de travail », est une représentation informatisée de la suite des tâches que comporte un processus).

L'informatique s'entrelace ainsi avec le travail des opérateurs humains. Chacune des activités que le processus fait se succéder comporte des opérations mentales (discernement, jugement, décision) ou physiques (donner un billet d'avion à un client, réaliser une opération de maintenance), les tâches mentales préparant les tâches physiques³ :

• dans une banque, un agent évalue l'opportunité d'ouvrir une ligne de crédit à un client ;
• dans une entreprise industrielle, un agent reçoit la commande d'un client et décide d'émettre un ordre de production vers l'atelier ;
• des manutentionnaires chargent et déchargent des camions que des chauffeurs conduisent à destination, des ouvriers contrôlent une machine-outil à commande numérique, etc.

La modélisation du processus définit donc conjointement le périmètre des activités et initiatives humaines et le contenu des applications que l'informatique met à leur disposition. Elle concrétise ainsi dans chaque processus l'alliage du cerveau humain et de l'automate.

Le système d’information s’organise désormais autour des processus de l’entreprise. C'est une innovation considérable : l’organisation de l'entreprise se conçoit sur le mode du travail (humain) assisté par ordinateur. Cela a fait passer au premier plan l’exigence de qualité des interfaces homme-machine - ainsi que celle du support aux utilisateurs, que la conception antérieure de l’informatique avait tendance à placer au dernier plan.

La modélisation des processus devient l’étape première et cruciale de l'informatisation. Il en résulte une articulation du système d’information aux modes de travail de chaque métier : pour qu'elle soit réussie il faut que les métiers s’impliquent dans la mise en forme et la maîtrise de leurs processus, qu’ils adhèrent à une démarche d’élucidation des processus.

Pour illustrer ce changement nous décrirons deux « modèles », M1 et M2. Dans M1 le système d’information se construit autour des applications informatiques, dans M2 il se construit autour des processus. Le rôle de l’informatique change⁴ lors du passage de M1 à M2. Ce changement n’est pas facile car il suppose de rompre avec des habitudes et il peut nécessiter un de ces changements de personne ou d’organigramme qui ne sont jamais les bienvenus.

Une informatisation à coup d'applications

Le fondement d’une application, tel que le définit Merise⁵, réside dans deux modèles : le modèle conceptuel de données, qui comprend les définitions sémantique⁶ et technique⁷ des données ; le modèle applicatif, qui décrit les traitements. Nous allons décrire deux scénarios de mise en œuvre du modèle M1 : le scénario rose montre comment les choses sont censées se passer, le scénario gris montre comment elles se passent souvent.

Scénario rose

L’application, dont la définition est fondée sur une expression des besoins sobre, pertinente, et sur des priorités clairement exprimées, limite la saisie au strict nécessaire, automatise les traitements et affiche sur l’écran (ou imprime sur papier) les résultats dont l'agent opérationnel a besoin. La récupération des données issues d’autres applications est automatique, seules les données nouvelles faisant l’objet d’une saisie manuelle.

L’informaticien, qui reçoit les demandes de divers utilisateurs, construit son architecture de données et de traitements. Il répartit les ressources (mémoire, puissance de calcul, débit des réseaux) et définit des applications intermédiaires ainsi que l’architecture des systèmes d’exploitation et langages sous une double contrainte de qualité⁸ et d’économie.

La cohérence des applications est alors assurée au sein du système informatique, cœur du système d’information. La qualité de l’écriture des programmes garantit qu’il sera facile de les faire évoluer quand les besoins changeront.

Scénario gris

L’urgence, l’insouciance, l’optimisme, le cloisonnement de l’organisation poussent à concevoir les applications au coup par coup selon l’arrivée des demandes et sans que leur relation avec les autres applications ne soit maîtrisée ; des données de référence⁹ sont définies séparément pour chaque application ; les plates-formes techniques (machines, système d’exploitation, langage) sont choisies en fonction des ressources disponibles lors du développement ; les interfaces présentées à l'agent opérationnel sont hétéroclites (touches de fonction et codages spécifiques à chaque application) et il doit souvent ressaisir les résultats d'une application pour alimenter une autre.

La « gestion de configuration » (documentation des versions successives d’une application) étant laissée à la bonne volonté des chefs de projet, certains la négligent. Beaucoup d’incidents restent inexpliqués.

Les métiers utilisateurs ont peu de prise sur l’évolution du système d’information. Même si la préparation du budget annuel prévoit une sélection parmi les projets que présentent les métiers selon leur utilité respective, rien ne garantit que ce programme sera effectivement réalisé : le budget qui lui est consacré n’est pas celui des métiers (qui considéreraient l’informatique comme un fournisseur) mais le budget de l’informatique, qui reste donc maître de l’affecter selon sa propre perception des priorités. Ainsi s'installe entre les informaticiens et l’entreprise une méfiance d'autant plus profonde que les engagements de l'informatique sur les coûts et délais ne sont pratiquement jamais tenus.

L’entreprise considère d'ailleurs l’informatique comme un centre de coût et non comme un investissement au service des métiers. Elle exerce sur le système d'information une pression budgétaire mécanique et aveugle par le moyen d'une « enveloppe informatique ».

L'approche de l'entreprise par les processus

Le système d’information vise à assister les agents opérationnels, selon la logique du travail assisté par ordinateur, dans la réalisation des tâches répétitives liées aux processus de production.

Les fonctions de la hiérarchie intermédiaire (transmission des consignes vers le bas et des rapports vers le haut) sont pour une large part remplacées par l’édition semi-automatique de comptes rendus. Le nombre des niveaux hiérarchiques étant ainsi réduit, la communication entre « base » et « sommet » est en principe plus facile.

Par ailleurs, l’approche par les processus facilite l’acquisition de compétences nouvelles par les agents. La transparence, la diffusion de l’information réduisent l’opacité des procédures, la rétention d'information et les abus que ces pratiques favorisent.

Chaque utilisateur va consulter ou saisir des données, déclencher des traitements : ceci conduit naturellement vers la programmation orientée objet. Pour décrire une interface utilisateur il suffit d’indiquer les données que celui-ci consulte, celles qu’il saisit, les traitements qu’il lance ainsi que l’ordre (éventuellement souple) dans lequel il réalise ces opérations.

Le langage UML¹⁰, qui fédère les langages de modélisation en approche objet, fournit les documents nécessaires pour décrire les activités (« cas d'utilisation »), les « classes¹¹ » (« diagramme de classes ») et la succession des opérations (« diagramme de séquences »). On construit ainsi le modèle qui, établi par un maître d’ouvrage¹² et communiqué au maître d’œuvre informatique, indique à ce dernier ce qui doit apparaître sur les écrans des utilisateurs, les actions que ceux-ci vont réaliser ainsi que des compteurs utiles à la supervision.

Le modèle d'un processus est plus précis que les spécifications fournies à l’informatique dans M1 : il indique ce que l'agent opérationnel doit faire et aide à découper le développement en « classes » reliées chacune à une finalité pratique (c’est pour cela que l’on parle d’« objets métier »).

L’analyse des activités fait apparaître que les mêmes « classes » peuvent être utiles à plusieurs acteurs, ou que l’on peut satisfaire les besoins de plusieurs acteurs en construisant des classes analogues (héritage, polymorphisme). Elle fait également apparaître que les mêmes classes sont souvent articulées au sein de « composants » qui les regroupent. Ces analogies et regroupements font naître des êtres sémantiques nouveaux qui concrétisent des concepts inédits, mais utiles.

L'effort réalisé lors de la modélisation allège l'effort de programmation, ce qui facilitera l'évolution ultérieure du système d'information et réduira les coûts de maintenance.

La mise en œuvre du modèle par l’informatique suppose que les programmes soient écrits dans un langages à objets (Java, C++, Eiffel etc.). Une articulation intelligente entre outils de développement et langages de modélisation permet de maîtriser la documentation des versions successives, qui incorporeront les mises à jour rendues nécessaires par l'évolution du métier.

Les échanges de messages entre objets ou avec les bases de données seront réalisés par un broker qui traitera l’adressage, le transcodage éventuel, et gérera la persistance pendant la durée d'une transaction (notamment la « concurrence », lorsque deux utilisateurs travaillent en même temps sur un même composant).

Des applications aux processus : un passage délicat

Le passage de M1 à M2 suppose un changement dans l'organisation autant que dans le système d’information. La responsabilité de celui-ci passe de l’informatique, qui la détenait traditionnellement, aux métiers qui définissent son contenu fonctionnel en modélisant leurs processus. L’informatique cesse alors d’être un centre de coût et devient un pôle d’investissement au service des métiers, l’entreprise renonce à la notion d’« enveloppe informatique ».

Les éléments essentiels du système d’information ne sont plus les applications mais les processus, objets et composants. Le soutien aux utilisateurs, qui dans M1 confinait au bizutage, devient une des priorités de l’informatique.

L’approche par les processus fait aussi passer l’entreprise du contrôle a priori (« le chef signe tout ») au contrôle a posteriori (« on agit d’abord, on fera si nécessaire un debriefing ensuite »), de l’opacité à la transparence (les retards deviennent visibles, qu’il s’agisse de la signature d'un décideur ou du travail d'un exécutant), de la rétention à la diffusion d’information.

*     *

Il ne faut pas sous-estimer les difficultés d'une telle évolution. Ceux qui pratiquent la rétention d’information tirent parti de l'opacité des procédures. Passer de M1 à M2 leur fait faire une traversée du désert pendant laquelle ils ne bénéficieront plus des protections que comporte M1 tandis que l'entreprise n'a pas encore atteint l’équilibre que permettra M2.

L'effort ne peut être accepté que si chacun perçoit ce qu’il peut y gagner. La communication, au sens médiatique du terme, est donc un élément crucial de la migration : il faut susciter l’espoir, éveiller l’intuition, et des problèmes techniques que l'on croyait insurmontables se règlent alors d’eux-mêmes (ou plutôt ils sont réglés dans la foulée).

Dans M1 la définition des applications reposait sur l’« expression de besoins ». Celle-ci suppose une interprétation du travail à faire par les utilisateurs, mais cette interprétation n’est pas toujours explicite : elle reste alors abstraite. Rien ne garantit qu’elle permettra un bon contrôle du processus puisqu’elle n’est pas construite à cette fin.

Dans M2 par contre le point de départ n'est pas la question « quels sont les résultats qu’il nous faut pour travailler » mais deux questions : « que produisons-nous », puis « comment produisons-nous ».

On découvre alors que tel processus ne boucle pas, n’est pas contrôlable ou comporte un même travail repris plusieurs fois, que certains points sont fragiles (lorsqu’une décision dépend d’un avis externe dont le délai n’est pas contrôlable). Modéliser le processus rend visibles certains phénomènes : un acteur doit répondre à un message dans un délai donné, ou bien la décision lui échappera.

Avec l'approche par les processus la conception du système d’information est une affaire d'abord sémantique et fonctionnelle : la maîtrise d’ouvrage doit se doter d’une expertise qui garantisse la pertinence de ses demandes en regard des exigences du métier. La modélisation UML fait abstraction des moyens techniques, quitte à accepter une révision si l'on constate un coût trop élevé lors de la conception du système informatique.

Ce dernier doit organiser les moyens techniques mis au service du processus. Il choisit les plates-formes, langages, interfaces, architectures (centralisée, client serveur à deux ou trois niveaux etc.), la localisation des traitements et mémoires, les niveaux de conservation des données, la couche de middleware et la gestion de la persistance. Il repose sur une expertise attentive à la diversité des outils du marché, aux innovations, à la pérennité des solutions et à leur coût.

Dans M1 la frontière entre maîtrise d’ouvrage et maîtrise d’œuvre était confuse. Certes la première était responsable de l’expression des besoins et la seconde de la réalisation technique, mais la cohérence du système d’information se concrétisait au sein de la seule informatique. La tentation était grande de confier à celle-ci plus qu’une mission de maîtrise d’œuvre, d’en faire le concepteur et l'arbitre du système d’information en la substituant aux métiers utilisateurs pour définir leurs besoins.

Dans M2 la séparation est claire. Au métier la responsabilité du modèle, à l'informatique celle de la solution technique. Cette répartition n’interdit pas le dialogue, elle le nécessite au contraire : la maîtrise d’ouvrage doit s’intéresser aux solutions techniques qui étendent le domaine du possible, le maître d’œuvre doit assurer une veille technique et signaler à la maîtrise d'ouvrage les opportunités ou les risques. À ce dialogue succède cependant la décision et alors chacun doit assumer ses responsabilités propres.

Processus et qualité

Dans une entreprise, un processus est d’abord un état de fait : un enchaînement de tâches visant à élaborer un produit, déclenché par un événement extérieur au processus (commande d’un client, décision d’un responsable) et se terminant par un événement lui aussi extérieur (livraison d’un produit, remise d’un rapport, etc.).

La notion de « livrable » est parfois utile pour désigner le produit (au sens large : rapports écrits, logiciels, comptes rendus, produits physiques etc.) auquel aboutit un processus. Un processus comporte des sous-processus quand sa progression nécessite la production de livrables intermédiaires : dans une banque, la décision qui conduit à accorder un crédit à une entreprise nécessite de boucler plus d'une dizaine de sous-processus.

La modélisation vise à expliciter la structure du processus, c’est-à-dire non seulement l’enchaînement des tâches et sous-processus mais aussi le délai imparti à chacun, l’identification des personnes auxquelles il faut envoyer un message lorsqu’une tâche est terminée, les indicateurs de qualité, les superviseurs auxquels ces indicateurs doivent être envoyés.

Il s’agit donc de documenter le processus en produisant les éléments suivants :

• plan de l’enchaînement des tâches (« diagramme d'activité ») ;
• interfaces propres à la réalisation de chaque tâche, donnant accès aux données et objets correspondants ;
• timers qui délimitent le délai maximum imparti à chaque tâche ;
• tables d’adressage qui indiquent l’adresse à laquelle le résultat doit être transmis lorsqu'une tâche est achevée, ainsi que celle à laquelle il faut envoyer la tâche si le timer a été dépassé ;
• compteurs et indicateurs permettant la supervision du processus ;
• outil d’administration comportant les adresses auxquelles il convient de faire parvenir les indicateurs.

Souvent les processus de facto (non informatisés) présentent des défauts que le système d’information devra corriger : piles LIFO (« last in first out », le dossier le plus ancien risque d'attendre indéfiniment), erreurs d'adressage, mauvaise conception des documents, mauvaise répartition de la charge de travail, redondances etc. Le modèle ne doit donc pas graver dans le marbre les processus existants : au contraire, la modélisation donne l'occasion de corriger leurs défauts. L'expérience montre que le gain en efficacité (donc l'économie en termes de coût) est souvent de l'ordre de 20 à 30 %.

Le pilotage d’un processus se fait normalement a posteriori : l’accent étant mis sur la fluidité et la rapidité, les opérateurs ont un devoir d’initiative et disposent des droits et habilitations correspondants. Le fonctionnement du processus engendre, si celui-ci a été convenablement outillé, des informations qui servent à le superviser : mesure des délais, des volumes de flux, de la qualité. Le superviseur définira les actions nécessaires pour redresser d’éventuelles mauvaises pratiques ou dérives soit en agissant sur les réglages du processus, soit en communiquant avec les agents opérationnels pour indiquer les corrections à apporter à leurs pratiques.

Les indicateurs que fournit le processus constituent par ailleurs une source d’information fine, en temps réel, qui peut être utilisée pour établir des comptes rendus destinés à divers responsables. Ainsi un processus de relation avec la clientèle et de relève des incidents peut alimenter des comptes rendus définis :

• par région, à l’intention des directeurs régionaux, en fournissant des tableaux comparatifs entre régions de sorte que chaque région puisse se situer par rapport à la moyenne;
• par produit, à l’intention des chefs de ligne de produit, de sorte que chaque produit puisse être suivi dans son évolution (notamment lors de la phase délicate du lancement initial).

Ces comptes rendus utiliseront une présentation synthétique (graphiques, petits tableaux de nombres) sous forme de séries chronologiques, car les évolutions importent souvent plus que les niveaux. Ils comporteront des commentaires qui apportent aux indicateurs un complément explicatif. Enfin, ils citeront des exemples « en texte intégral » (une lettre de réclamation typique...) choisis pour leur représentativité et qui donneront au compte rendu un tour concret et vivant.

La préparation et la diffusion des comptes rendus supposent en outre d'élaborer des tables de diffusion et de gérer des droits d’accès : c'est un travail éditorial qui requiert des compétences élevées.

Les considérations ci-dessus sont en rapport direct avec la réalité des tâches quotidiennes et les urgences de l’entreprise.

La conception du système d’information à partir des applications s'est révélée peu pratique et coûteuse. En effet lorsque l’on suit cette approche la priorité n’est pas d’expliciter, documenter et maîtriser la succession logique et chronologique des tâches qu'accomplissent les agents opérationnels, mais de leur présenter des informations et outils de traitement censés leur faciliter la tâche. La mise au point des applications est par ailleurs scandée par le calendrier budgétaire et elle suit une procédure souvent plus formelle que rationnelle.

Dans un monde idéal la remarque ci-dessus ne s’appliquerait pas¹³ car rien n’empêche bien sûr en principe de s’intéresser aux tâches accomplies par les agents opérationnels lorsque l’on développe et maintient une application. Cependant en pratique les applications sont conçues sans que l’on considère le processus que constitue la succession de ces tâches.

On s’efforce alors de corriger les dysfonctionnements en perfectionnant, enrichissant, compliquant les applications, ou encore en achetant sur le marché des progiciels censés résoudre tous les problèmes : il faudra encore les paramétrer, les adapter, les maîtriser, et leur mise en œuvre provoquera souvent des coûts imprévus.

Tout le monde est alors mécontent : les dirigeants constatent la persistance des dysfonctionnements malgré des efforts coûteux, les agents opérationnels disent que l’informatique répond mal à leurs besoins, l’informatique estime faire de son mieux et s’étonne de recevoir des reproches.

Il faut donc demander au système d’information non plus de fournir des applications, mais d’équiper les processus de l'entreprise.

Nous décrirons d’abord les apports d’un workflow et de la documentation partagée, puis nous donnerons des exemples opérationnels. Nous verrons ainsi apparaître les fonctions d'animateur de forum, d'administrateur de processus etc.

Mise en œuvre

Il est facile d'outiller avec un workflow simple le traitement des demandes d’autorisation d’achat et d’autorisation d’investissement, ou encore la préparation du budget. Ces processus sont analogues : une demande ayant été formulée par quelqu’un, elle doit être validée par son responsable hiérarchique, vérifiée par le contrôle de gestion, éventuellement soumise à des avis d’experts et enfin proposée un décideur qui est le plus souvent le directeur général. Des tableaux doivent être construits pour avoir une vue synthétique des budgets demandés et accordés, des engagements de dépense etc.

Nous allons décrire la façon dont les choses se passent avant l'informatisation, puis comment elles se passent avec un workflow.

Avant l'informatisation

Des dossiers sont établis selon des formats variables, les calculs sont divers et parfois confus, des allers et retours avec le demandeur sont nécessaires pour obtenir une formulation compréhensible de sa demande.

Puis chaque dossier part dans le circuit des avis et signatures. Il peut rester longtemps sur un bureau, l'empilement selon le mode LIFO suscitant des délais aléatoires. Il est toujours difficile de savoir où en est un dossier. Certains font attendre longuement une signature qu’ils utilisent comme monnaie d’échange dans une négociation. Il arrive aussi qu’un dossier se perde.

Les comptes résultant de ce flux d’affaires sont établis par des personnes qui se trouvent en fin de processus, en général au contrôle de gestion, et utilisent des tableurs. Des erreurs de saisie sont possibles ainsi que des oublis matériels. Des vérifications et recoupements sont nécessaires. Ils consomment un temps de travail important et ne suppriment pas toute incertitude. Lors de la réunion avec le directeur général certaines incertitudes apparaissent et occasionnent des disputes irritantes.

Après l'informatisation

Les dossiers électroniques sont établis sur des masques de saisie qui comportent une aide en ligne, les calculs (totaux, taux de rentabilité, ratios, reports de crédits, etc.) sont automatiques, les données de référence (montant du budget disponible, nomenclatures, etc.) sont fournies par des services contextuels. Le dossier comporte une indication sur l’urgence et le délai souhaité de traitement.

Lorsqu’une tâche est terminée, le dossier est transmis automatiquement à l'agent suivant qui est prévenu par une alerte sur son écran. La file d’attente classe les dossiers selon leur date d'arrivée ou, mieux, selon leur urgence.

L'agent consulte le dossier, le traite, y note des avis et décisions qu'il authentifie par sa signature électronique. Le délai de traitement est préprogrammé : s'il est dépassé, le dossier est transmis à une autre personne. En cas de non traitement persistant une alarme est émise vers le responsable du processus.

Les droits d’accès aux documents ou à des parties de documents sont gérés par l’administrateur du processus. Une personne habilitée peut, à tout moment, consulter le workflow pour savoir où en est un dossier, connaître les avis qui ont été donnés, intervenir si nécessaire.

Le processus articule des sous-processus et boucle sur la réponse à la demande initiale : la réponse à une demande budgétaire, c’est le montant accordé (éventuellement nul) ; la réponse à une demande d’achat, c’est la livraison du bien demandé et elle doit faire l’objet d’un accusé de réception.

Le propriétaire du processus reçoit régulièrement des statistiques : affaires traitées classées par nature, histogramme des délais, montants concernés selon les nomenclatures comptables, incidents, anomalies, etc. Il a les moyens de repérer les activités qui dépassent souvent les délais : il peut soit allonger le délai qui leur est accordé, soit émettre un rappel à l’ordre.

Quelques exemples

Nous considérerons ici les conséquences d'une informatisation réussie sur la documentation professionnelle, les relations entre les entreprises etc.

La documentation

La documentation sur papier présente toujours des défauts : on ne sait jamais si elle est à jour, elle s’égare le long des circuits de diffusion, des versions successives s’empilent souvent sans classement, il est enfin difficile d’y faire des recherches.

L'Intranet permet, si l'on s'y prend bien, de mettre à la disposition des agents opérationnels une documentation électronique à jour. Elle peut être aussi dotée d’outils facilitant la recherche et l'aide contextuelle ainsi que la formation en ligne.

La documentation électronique doit être associée à un forum où les utilisateurs peuvent poser des questions à la cantonade et recevoir des réponses : un animateur veillera à ce que les réponses soient fournies rapidement et purgera le forum des redondances ou banalités. Progressivement, le forum entoure ainsi la documentation d’un commentaire précieux¹⁴.

Les relations entre les entreprises

L’expression « entreprise étendue » désigne une entreprise dont le système d’information communique avec celui de ses clients, fournisseurs et partenaires. Historiquement, les premières entreprises étendues se sont mises en place entre grandes entreprises et fournisseurs réguliers grâce à l’EDI¹⁵, par exemple entre constructeurs automobiles et fournisseurs de pièces détachées, de peinture, etc. : il s’agissait de faire communiquer des applications informatiques.

L’Extranet permet de faire communiquer des processus et cela confère une souplesse et une puissance nouvelles à l’entreprise étendue. Vers les partenaires et les fournisseurs se bouclent des sous-processus qui permettent de constituer l’offre : cela suppose les systèmes d'information interopérables, c'est-à-dire que les données et documents utilisés de part et d'autre soient définis de façon cohérente¹⁶.

Le processus de la relation avec les clients doit être transcanal : quel que soit le canal utilisé par un client pour communiquer avec l'entreprise (rencontre physique, téléphone, courrier sur papier, courrier électronique, site Web) l'échange doit pouvoir se poursuivre de façon cohérente et sans redondance.

Le fonctionnement d’un partenariat demande d’une part l'interopérabilité des processus opérationnels, d'autre part la transparence du partage des coûts et recettes. Si le processus opérationnel ne fonctionne pas, le partenariat sera inopérant. Si le processus financier est opaque, le partenariat sera peu durable car il sera pollué par la fraude ou le soupçon de fraude.

Autres exemples

Citons quelques autres dispositifs utiles et dont l’implantation ne pose aucun problème technique (mais elle pose quelques problèmes d’organisation) :

1. Mise en réseau du relevé des décisions prises lors d’une réunion, validé par la personne qui présidait la réunion, accessible aux participants et bouclant sur le compte rendu d’exécution des décisions ;
2. Mise à disposition de résultats statistiques (enquête sur la satisfaction des clients, statistiques commerciales, statistiques commerciales, etc.) ;
3. Traitement des réclamations des clients : un workflow permet de contrôler le délai de traitement, d’établir automatiquement des statistiques, etc. ;
4. Gestion des incidents : il est avantageux de compléter la documentation électronique par un relevé des incidents qui permettra d’établir des statistiques, puis de faire évoluer les procédures ;
5. Indicateurs stratégiques : un datawarehouse permet de constituer et documenter des indicateurs agrégés consultables par les personnes habilitées. Un workflow fait circuler synthèses, graphiques et commentaires ;
6. Formation professionnelle : les stages sont complétés par du télé-enseignement (accès aux supports de cours, auto-évaluation, forum).

Cerveau + Automate = Informatique

Nous sommes arrivés sans crier gare au point culminant d'une évolution, au basculement d'un système technique à l'autre. L'économie mécanisée qui s'est déployée à partir de 1775 était fondée sur l'alliage de la main humaine et de la machine, et cet alliage a eu d'immenses conséquences économiques, sociologiques, culturelles et géopolitiques.

L'économie informatisée qui se déploie depuis 1975 est fondée, elle, sur l'alliage du cerveau humain et de l'automate. Cet alliage se manifeste à petite échelle, mais de façon très concrète, avec l'informatisation des processus : le « cerveau d’œuvre » a succédé à la « main d’œuvre » en tant que ressource fondamentale du système productif.

Cela aura des conséquences économiques, sociologiques, culturelles, géopolitiques différentes sans doute de celles qu'a eues l'économie mécanisée, mais d'ampleur comparable. Elles se manifestent déjà avec la mondialisation (que les réseaux informatiques favorisent), le foisonnement du Web sur l'Internet, l'Internet des objets, enfin l'informatisation du corps humain lui-même avec le téléphone « intelligent » et autres prothèses.

L'informatisation n'apparaît plus alors comme une opération technique qui se résumerait à la conception et la mise en œuvre d'applications, mais comme une transformation radicale des conditions de l'action humaine, du fonctionnement du système productif et, plus largement, de la vie en société. Cette transformation ouvre des possibilités nouvelles et s'accompagne de risques nouveaux. L'approche par les processus, que nous avons décrite, en est un épisode crucial.

Si l'on pouvait revenir à l'étymologie d'« informatique » – « information + automate » – puis à celle d'« information » (« donner à un être humain une forme intérieure », c'est-à-dire une capacité d'action¹⁷), on dirait qu'« informatique » désigne adéquatement l'alliage du cerveau humain et de l'automate et qu'« informatisation » convient pour désigner les conséquences qu'aura l'émergence de cet alliage.

Malheureusement les mots « informatique » et « informatisation » sont parasités par des connotations péjoratives. Au risque de provoquer des contresens, la case sémantique qu'ils auraient pu remplir est désormais occupée par « numérique » et « numérisation » dont l'étymologie est pourtant plus pauvre (rien n'est plus étroitement technique que le codage numérique par des 0 et des 1 !).

Des contresens sont sans doute inévitables dans une période de transition entre deux systèmes techniques, lorsque ni les institutions, ni les habitudes, ni les façons de penser ne se sont adaptées au monde nouveau.

Dans beaucoup d'entreprises le passage des applications aux processus s'est ainsi produit sans que l'on n'en tire les conséquences : le dosage et, peut-on dire, les conditions de cuisson qu'il faut respecter pour que l'alliage du cerveau humain et de l'automate soit efficace sont encore généralement ignorés.

Il arrive ainsi que l'on automatise à outrance, en empêchant les opérateurs humains d'user en cas d'incident du bon sens qu'aucun automate ne peut posséder : on a ainsi fait confiance, dans la finance, à des empilages d'algorithmes ultra-rapides que ni les opérateurs, ni les superviseurs, ni même leurs concepteurs ne peuvent maîtriser intellectuellement. La catastrophe était (et reste) inévitable.

Il ne convient pas d'ailleurs de traiter le cerveau d’œuvre comme on a pu, dans l'économie mécanisée, croire devoir traiter la main d’œuvre. Beaucoup d'entreprises ont conféré de facto des responsabilités aux agents opérationnels sans leur accorder de jure la légitimité correspondante : il en est résulté une épidémie de stress dont nous avons de nombreux témoignages.

De cette crise de transition résulte une inefficacité massive, d'autant plus que la brusque délocalisation de la production mécanisée vers des pays émergents contraint les anciens pays industrialisés à réaliser dans l'urgence une transition déjà délicate vers le système technique informatisé : leurs économies, déséquilibrées, retrouvent la « pauvreté dans l'abondance » paradoxale qui a caractérisé la crise des années 30.

Il ne semble pas que les politiques soient prêts à comprendre ce phénomène, ni à prendre les dispositions qu'il réclame. Par contre les entreprises peuvent, à l'échelle certes modeste mais très concrète de leurs processus et sous l'aiguillon de la nécessité, s'efforcer de trouver la bonne articulation, le bon dosage dans l'alliage du cerveau humain et de l'automate. Certaines sont en avance sur les autres : comme au début de la mécanisation, c'est l'observation puis la dissémination de bonnes pratiques en matière d'informatisation des processus qui permettront de sortir progressivement de la crise de transition.

____
¹ Niklaus Wirth, Algorithms + Data Structures = Programs, Prentice Hall, 1976.
² Voici une règle de reroutage typique : si X n’a pas traité le message dans le délai voulu, router vers Y (collaborateur de X). Si chez Y le délai est de nouveau dépassé, router vers Z (supérieur de X). Ce type de règle favorise le traitement rapide des dossiers.
³ Ainsi dans la conduite d’une voiture la perception (je vois le feu rouge), le jugement (il faut m’arrêter), la décision (je veux m’arrêter) préparent l’action (je freine) et son résultat (la voiture s’arrête).
⁴ Nicholas Negroponte, Being Digital, Alfred A. Knopf, 1995.
⁵ Merise est une méthode d'analyse et de conception de projet informatique qui s'appuie sur les travaux d'Hubert Tardieu. Elle a eu une grande influence dans les années 1980.
⁶ Définition, type de donnée (quantitative, qualitative, ordinale, cardinale etc.), champ d’observation, grain de détail, périodicité de l’observation, etc.
⁷ Format, méthode d’estimation des données manquantes, délai de mise à jour, conditions de la consultation (temps réel, temps différé), droits d’accès, etc.
⁸ Fiabilité (absence de pannes), délai de la mise à jour, rapidité de la réponse.
⁹ Données partagées par plusieurs applications et qui devraient donc être répliquées dans chacune à partir d’un lieu de stockage et de mise à jour unique : tables de codage, taux de change etc.
¹⁰ « Unified Modeling Language » ; cf. Martin Fowler, UML distilled, Addison Wesley, 1997.
¹¹ Dans les langages de programmation à objets on nomme « objet » la représentation informatique d'un être réel (produit, client, fournisseur etc.), et « classe » l'ensemble des objets de même nature (« classe produit », « classe client » etc.).
¹² On entend souvent dire « la distinction entre maîtrise d'ouvrage et maîtrise d’œuvre ne signifie rien, elle est franco-française ». Ce qui se passe aux États-Unis, au Japon etc. montre pourtant que cette distinction se retrouve partout, seul étant particulier à la France un vocabulaire que l'usage a consacré et qui ne protège peut-être pas assez envers les contresens.
¹³ De même dans un monde idéal les développeurs s’organiseraient pour pouvoir réutiliser les logiciels qu’ils produisent. Certains le font mais dans le monde réel la plupart d’entre eux ne le font pas : les langages orientés-objet ont été conçus pour faciliter la réutilisation.
¹⁴ Ainsi les forums mis par les fournisseurs de logiciels à la disposition des développeurs contiennent, au bout de quelque mois, les réponses qui permettent de traiter les bogues du logiciel et les astuces qui aident à en tirer le meilleur parti.
¹⁵ « Échange de données informatisé ».
¹⁶ Pascal Eymery, La logistique de l’entreprise, Hermès 1997.
¹⁷ Le sens le plus courant d'« information » (les « informations de vingt heures ») et le sens que ce mot reçoit dans la « théorie de l'information » de Shannon s'écartent tous deux de cette étymologie.