2.2 - Ingénierie des processus

Pour pouvoir informatiser un processus il faut disposer d’un langage de modélisation qui permette à chacune des parties concernées de s’exprimer pleinement et qui fournisse à l’informatique des spécifications exactes : c’est le but d’UML (Unified Modeling Language) (Booch, Jacobson, Rumbaugh et Rumbaugh [3] ; Roques et Vallée [32]).

Démarche de modélisation

La démarche de modélisation a été standardisée par l’OMG (Object Management Group) avec la MDA (Model Driven Architecture) (Miller et Mukerji [21]). Elle procède par enrichissement progressif sans bousculer l’ordre des étapes [« L’optimisation prématurée est la racine de tous les maux » (Knuth [17])] : il ne faut pas se lancer dans la modélisation proprement dite sans disposer de l’expression de besoin, ni documenter les cas d’utilisation avant d’avoir produit le diagramme d’activité etc.

Chaque étape aboutit à une livraison qui doit être validée par les parties prenantes pour éviter un effet de tunnel dans la modélisation, et cette validation conditionne le passage à l’étape suivante [L’effet de tunnel doit être évité également dans la réalisation : si l’automatisation du processus requiert un travail lourd (et donc long) il faut définir des « livrables exploitables », produits intermédiaires que l’on pourra mettre en exploitation dans les mains des utilisateurs].

Il faut associer plusieurs techniques informelles et formelles pour saisir les diverses facettes du problème sans le dénaturer, puis pour le détailler dans un modèle que l’on pourra ensuite préciser et modifier. Cela permet de s'adresser à des interlocuteurs ayant des intuitions de forme différente.

Il se peut que l’on découvre lors d’une étape des contraintes qui obligent à réviser le résultat des étapes antérieures. Si la documentation est correcte, si les outils facilitent la cohérence entre les étapes, si le modèle est modulaire, le travail nécessaire à ces révisions restera raisonnable.

Une fois l’expression de besoin formulée, il convient d’établir le dictionnaire du domaine considéré ; puis une approche systémique en fournit une vue globale. La définition des modèles conceptuels, enrichie par la prise en compte des règles de gestion, accompagne la modélisation. Enfin, les cas d’utilisation détaillent ce que le modèle doit effectuer au sein du système global.

Tout comme une base de données le modèle est un être informatique que personne ne peut apercevoir dans son entier mais seulement à travers des « vues » adaptées chacune à une catégorie d’interlocuteurs et qui en révèlent un aspect particulier. Ces vues sont fournies par des diagrammes : nous présenterons les principaux d’entre eux.

L’expression de besoin

Il faut d’abord savoir ce que l’entreprise veut faire, ce qu’elle veut produire et comment elle veut le produire. L’« ingénierie des besoins » (requirement engineering) doit s’appuyer sur une « expression de besoin » pertinente, sobre et cohérente avec le reste de l’entreprise et du SI.

L’expression de besoin est un document court (quelques pages) en langage naturel. Ce document est crucial car tout projet se découpe en travaux parcellaires durant lesquels on risque, ayant perdu de vue le but visé, de ne plus savoir faire des arbitrages de bon sens : il sera alors utile de revenir à l’expression de besoin qui est donc une référence fondamentale pendant toute la durée du projet.

La demande n’est pas le besoin, elle n’en est qu’un symptôme. Il faut donc, pour diagnostiquer le besoin, interpréter ce que demandent les dirigeants et les utilisateurs. Souvent en effet leur demande spontanée n’est pas pertinente : « je veux un bouton sur l’écran pour déclencher tel traitement », « il nous faut un serveur Unix pour fidéliser les clients » etc. On doit mettre de telles demandes de côté et poser la question « que voulez-vous faire » ou « à quel problème voulez-vous répondre ? ». Cette question s’adresse aux « métiers » de l’entreprise, maîtrises d’ouvrage (MOA).

Chaque métier est un être organique et donc complexe : les agents opérationnels, utilisateurs du SI, sont les plus nombreux sur le terrain où ils sont encadrés par des managers opérationnels ; à la DG, le directeur est un stratège qui oriente le métier, entouré d’experts et concepteurs qui le conseillent et l’assistent. Cette pyramide se découpe encore, ainsi que les missions et processus du métier, en sous-directions et services que le stratège coordonne.

Chaque métier est ainsi comme une entreprise dans l’entreprise, et comme elle il fédère des spécialités mutuellement jalouses : le stratège doit arbitrer entre des services qui rivalisent pour le partage des ressources.

Il faut faire émerger de cette complexité une expression de besoin claire, résultant d’un consensus autour des priorités : la produire est une des tâches de la « maîtrise d’ouvrage déléguée ». Beaucoup de projets souffrent de l’imprécision ou de la versatilité de l’expression de besoin ainsi que de conflits « politiques ». C’est pourquoi il faut s’assurer du consensus des dirigeants concernés ainsi que de l’authenticité de la validation par le stratège.

La maîtrise d’ouvrage déléguée (MOAD) La décision comme la responsabilité appartiennent, en ce qui concerne le SI, au dirigeant (ou « stratège ») de l’entité considérée (DG, directeur, chef de service etc.). Il délègue une mission d’expertise à une MOAD, personne morale placée sous son autorité et qui lui soumet, puis met en œuvre, les décisions concernant les expressions de besoin, la modélisation, le pilotage des projets, le déploiement des solutions, la formation des utilisateurs et la dissémination des bonnes pratiques. La MOAD doit savoir parler trois langages : celui du stratège, celui de la maîtrise d’œuvre informatique (MOE) et celui des utilisateurs, afin de les aider à communiquer et à se comprendre. Elle doit notamment être pour l’informatique un client compétent. D’une entreprise à l’autre le vocabulaire varie mais quelle que soit sa dénomination la présence d’une MOAD qualifiée dans chacun des métiers conditionne la qualité du SI. La « gouvernance » du SI culmine dans la personne du DG, assisté par une MOAD centrale qui assure en outre l’animation et la coordination des MOAD des « métiers ». L’expérience montre que l’implication personnelle du DG est condition nécessaire de la qualité d’un SI.

La rédaction d’une expression de besoin passe par plusieurs étapes :

• recueil de la demande spontanée auprès de personnes qui représentent les utilisateurs (« experts métier ») et des dirigeants ;
• classement des demandes par ordre de priorité, sélection de celles qui sont absolument nécessaires ;
• confrontation à l’état de l’art des SI et aux exigences de la cohérence ; recueil des avis des dirigeants, obtention d’un consensus ;
• validation par le directeur, stratège du métier.

Pour que la validation soit authentique (c’est-à-dire pour que le stratège se sente vraiment engagé par sa signature), il faut que l’expression de besoin lui présente clairement le but visé, la façon dont on envisage de l’atteindre, et explique pourquoi cette façon-là est jugée préférable à d’autres éventuellement possibles.

Le modèle UML

Le dictionnaire rassemble les définitions des termes relatifs au système considéré. On doit être tolérant lors du recueil de la terminologie du métier et accepter de noter les homonymes et synonymes qui coexistent dans l’organisation. La construction du modèle apportera une réduction terminologique en n’associant plus qu’un nom et un seul à une même chose ou à un même concept : l'amélioration du vocabulaire est l’un des apports de la modélisation.

Un schéma général, validé par les acteurs, met en évidence les structures de l’entreprise impliquées, leurs responsabilités et leur mode de coopération en utilisant la notion de « flot d’information » d’UML.

Le schéma général

La notion de « contrainte » dans UML permet de modéliser des règles de gestion qui autorisent, provoquent ou empêchent le déroulement d’un processus (« une direction départementale ne doit pas comporter plus de dix agences », « un client ne peut commander via le Web que s’il a été enregistré au préalable », « un employé marié ne doit être muté qu’en dernier recours » etc.).

Décrire un processus, c’est décrire l’événement qui le déclenche, les étapes (ou activités) par lesquelles il doit passer, les ressources qu’il doit consommer et l’événement final auquel il aboutit. Ces informations sont rassemblées et documentées dans le diagramme d’activités qui montre la succession des activités, les messages qu’elles échangent, les éventuels sous-processus et les livraisons intermédiaires que ceux-ci fournissent.

Diagramme d'activité

Des diverses vues sur le modèle, le diagramme d’activité est la plus lisible et la plus facilement compréhensible pour les personnes qui ne participent pas à son élaboration mais doivent le valider. L’étape suivante consiste à décrire les cas d’utilisation, chaque activité en comportant un ou plusieurs. Un cas d’utilisation regroupe des opérations que l’acteur exécute et qui forment un ensemble cohérent : recevoir des messages, consulter des données ou du texte, saisir des données ou du texte, lancer des traitements, envoyer des messages.

On a défini le cas d’utilisation lorsque (1) on l’a nommé et désigné par sa finalité au sein de l’activité, (2) on a décrit son contenu en définissant les données consultées, saisies ou traitées, la nature des traitements, les messages échangés, (3) on a identifié les composants qu'il met en œuvre au sein du système informatique.

Il arrive que des cas d’utilisation divers comportent des éléments semblables, ou qu’ils soient des cas particuliers de cas d’utilisation plus généraux : on définit alors une hiérarchie de cas d’utilisation qui, par abstraction, simplifie le modèle : c’est le diagramme des cas d’utilisation.

Pour valider un cas d’utilisation on présente aux utilisateurs futurs une succession d’écrans simulant l’exécution du processus.

Dans les langages à objet, chacune des populations que le SI décrit (clients, produits etc.) est une « classe » et la représentation de chacun des individus est un « objet ». Chaque objet contient les attributs qui décrivent l’individu ainsi que des fonctions (« méthodes ») qui agissent sur ces attributs, notamment les interfaces qui permettent de les tenir à jour.

Le diagramme de classes indique les relations entre classes : l’emboîtage conceptuel des classes filles dans les classes mères est nommé « héritage » (les classes « particulier » et « entreprise » ont dans le diagramme ci-dessous les attributs de la classe « élément », plus d’autres qui leur sont propres), la relation organique entre deux classes est nommée « agrégation » (la classe « adresse » est agrégée à la classe « élément »).

Exemple de diagramme de classes

Le diagramme de classes exprime sous une forme commode pour l’informaticien la structure conceptuelle des populations que le processus considère et il est bien adapté à la programmation dans un langage à objets. Cependant ce diagramme sera, contrairement au diagramme d’activité, d’une lecture difficile pour les autres parties concernées.

Le diagramme de séquence représente la succession chronologique des opérations réalisées par un agent lors d’une activité : saisir une donnée, consulter une donnée, lancer un traitement ; il indique les objets que l’agent va manipuler et les opérations qui font passer d'un objet à l'autre.

Le diagramme d'état représente la façon dont évoluent durant le processus les objets appartenant à une même classe (« cycle de vie »). La modélisation du cycle de vie est essentielle pour représenter et mettre en forme la dynamique du système avec les pré-conditions et post-conditions vérifiant les unes qu’une activité peut commencer, les autres qu’elle est terminée.

Modélisation et évaluation du coût

L’évaluation du coût du projet progresse à mesure que sa définition se précise.

1. l’expression de besoin n’est accompagnée d’aucune évaluation ; on peut tout au plus lui associer une indication qualitative comme « petit projet », « projet moyen », « gros » ou « très gros » ;
2. si l’expression de besoins passe le cap de la sélection, une « étude préalable » est lancée. La maîtrise d’œuvre fournit une esquisse de solution et une évaluation du coût : la marge d’erreur est alors de l’ordre de 50 % par rapport au coût réel : si l’on estime le coût à 10 millions d’euros, le coût final sera vraisemblablement dans la fourchette de 5 à 20 millions. Quoique imprécise, cette estimation sert à évaluer la rentabilité du projet (Peaucelle [28]) (à ce stade l’évaluation des gains que l’on peut en attendre est d’ailleurs tout aussi imprécise) ;
3. si l’étude préalable est convaincante, l’entreprise lance la modélisation et celle-ci permet de resserrer l’évaluation ;
4. si l’entreprise décide de lancer le projet au vu du modèle, la maîtrise d’œuvre consulte des entreprises dont les réponses permettent de la préciser encore ;
5. il arrive enfin souvent qu’on la révise lors de la réalisation : on ne connaîtra vraiment le coût qu’à la fin du projet.

Un « modèle de coût » étalonné et condensant l’expérience des informaticiens ne supprime pas l’incertitude, mais il peut la réduire et améliorer d’autant la qualité des décisions relatives au lancement des projets (Printz [29]). Lorsque les décisions sont prises sur la base d’une évaluation imprécise, cette imprécision doit être considérée comme l’un des risques associés au projet.

L’informatique de communication

Outre l’informatisation des processus, le SI offre aux agents des outils qui, permettant une communication informelle, complètent utilement le formalisme des processus. Il ne s’agit plus de traiter des données : les ordinateurs sont utilisés pour envoyer du courrier (messagerie), partager les agendas, diffuser la documentation, etc.

L’informatique de communication utilise des données structurées (dans le carnet d’adresse de la messagerie, dans les masques de saisie ou de consultation de la documentation électronique), mais elles ne représentent qu’une faible partie du volume total de l’information manipulée. Les textes envoyés par messagerie, ou consultables sur l’Internet, écrits en langage naturel, utilisent la souplesse et la puissance de communication de ce langage.

La messagerie permet une communication asynchrone en langage naturel. Elle comporte des pièges : l’expérience montre qu’elle est un amplificateur de l’agressivité et que de mauvais usages peuvent annuler son apport à l’entreprise.

Il est donc utile de désigner un administrateur de la messagerie, personne morale chargée de superviser le service. Il dispose d’outils qui, sans qu’il ait à ouvrir les messages, lui permettent de détecter les mauvaises pratiques et de conseiller les utilisateurs : abus des listes de diffusion, boîtes aux lettres jamais ouvertes, émission de messages trop longs, réception de messages trop nombreux etc.

La messagerie sert utilement de poisson pilote au transfert de fichiers et elle peut servir aussi de plate-forme de workflow pour des processus simples.

Les adresses des utilisateurs de la messagerie sont stockées dans un annuaire électronique qui peut être enrichi et contenir également le numéro de téléphone, l’adresse postale, la photographie, la description des fonctions etc. de la personne. On peut introduire dans l’annuaire assez d’informations pour alimenter le profil de la personne : cet annuaire jouera alors un rôle central dans le SI en facilitant la gestion des habilitations.

L’agenda électronique permet aux personnes d’organiser leur emploi du temps ; couplé à un ordinateur de poche, il remplace avantageusement l’agenda papier. Mis en réseau, il facilite l’organisation des réunions et la prise de rendez-vous par un(e) assistant(e) ou un(e) collègue.

La documentation électronique, accessible aux agents sur l’Intranet de l’entreprise, remplace avantageusement la documentation sur papier : elle permet de mettre à disposition sans délai des textes à jour, elle évite les oublis de la diffusion sur papier ainsi que l’empilage de notes apportant des corrections aux versions antérieures, elle compense dans une certaine mesure l’inégalité entre les établissements de l’entreprise (directions régionales, direction générale) en ce qui concerne l’accès à l’information. Le moteur de recherche aide à trouver facilement la réponse à une question, les liens hypertexte permettent de relier entre eux les documents concernant des thèmes voisins.

La dissémination sélective vise à fournir à chacun la documentation dont il a besoin et uniquement celle-là. L’une des solutions les moins coûteuses consiste, partant d’une démarche de marketing interne qui permet de classer les agents selon leurs besoins, à diffuser des newsletters qui contiennent des liens hypertexte vers les documents dont la consultation est utile et leur associent un bref commentaire : elles font ainsi connaître les nouveautés de la documentation, en publient des revues thématiques etc.

Lorsque plusieurs personnes concourent à la production d’un même document la gestion des versions successives est toujours délicate : il faut éviter la collision entre des corrections portant sur un même paragraphe (« concurrence »), l’incohérence que provoquent des révisions mal coordonnées, les ruptures de ton et de forme résultant de la diversité des rédacteurs. Des outils de rédaction coopérative aident à surmonter ces difficultés.

Le forum permet aux agents de poser des questions à la cantonade lorsque la documentation est incomplète ou ambiguë, et aux experts d’apporter des réponses qui entoureront la documentation d’un halo de commentaires. Un forum doit être animé : l’animateur purge les messages obsolètes ou non pertinents en regard du thème du forum, introduit dans le corps de la documentation le contenu des messages importants et sollicite les experts pour que toute question reçoive une réponse dans un délai décent.

Pour réaliser une enquête interne à l'entreprise (par exemple une enquête de satisfaction sur les apports du SI à l’activité professionnelle), on peut construire un échantillon par tri dans l’annuaire puis envoyer aux personnes enquêtées un message contenant un lien vers le formulaire stocké sur un serveur Web. On peut ensuite programmer des relances vers celles qui n’ont pas répondu. Des programmes produiront automatiquement les tris à plats, tris croisés et représentations graphiques qui facilitent l’interprétation des résultats de l’enquête.

Les cadres, les commerciaux en déplacement chez les clients ou les partenaires veulent pouvoir accéder depuis l’extérieur au SI de l’entreprise. Cela pose d’évidentes questions de sécurité auxquelles on peut répondre par un contrôle du mot de passe et par une gestion stricte des habilitations.

Des plateaux téléphoniques sont utilisés pour la communication interne (notamment le dépannage des utilisateurs du SI) et ils sont aussi une composante importante de la relation transcanal avec les clients. La pertinence de l’interface fournie aux opérateurs du plateau téléphonique est l’un des enjeux importants du SI.

Beaucoup d’entreprises croient faire une économie en externalisant les plateaux téléphoniques. Elles perdent ainsi les informations et l’expérience précieuses que l’on y acquiert. Dans les entreprises efficaces, un directeur ne pense pas déchoir en passant quelques jours au plateau téléphonique et en coiffant le micro-casque pour répondre lui-même aux clients et aux utilisateurs du SI.