NB : ce texte sommaire n'épuise pas le sujet, auquel je consacrerai prochainement un développement mieux construit.

Priorité des usages

Le rôle du système d’information dans les entreprises est en train de changer. La décentralisation de puissance et mémoire induite par la dispersion des micro-ordinateurs les oriente vers de nouvelles architectures, ainsi que vers un partage différent des responsabilités entre utilisateurs du système d’information et informaticiens. Un ensemble de techniques, regroupées sous le terme de " nouvelles technologies ", modifie le champ du possible : client-serveur, orienté objet, Intranet, Datawarehouse, Datamining, Workflow etc.

La définition habituelle du système d’information ressemble encore à ceci : " Le système d’information est l’ensemble des informations formalisables circulant dans l’entreprise et caractérisées par des liens de dépendance, ainsi que des procédures et des moyens nécessaires pour les définir, les rechercher, les formaliser, les conserver, les distribuer".

Mais cette définition concerne l’objet, non sa dynamique : elle n’indique ni à quoi sert le système d’information, ni comment il est construit. Pour décrire cette dynamique, il faut distinguer les deux faces du système d’information : l’une orientée vers les moyens (système informatique), l’autre vers les besoins et les usages, auxquels le système d’information donne une place de plus en plus prioritaire.

Les moyens de l’informatique sont la puissance de calcul (mesurée en MIP(1)), la mémoire (mesurée en octets), l’" intelligence " (logiciels), les réseaux (largeur de bande, protocoles).

L’offre de machines et logiciels foisonne. Elle est évolutive, la concurrence est féroce. L’informaticien doit connaître les produits et les " passerelles " qui permettent de les faire communiquer. Il faut être du métier pour interpréter les annonces des fournisseurs et choisir la " solution " (combinaison de composants matériels et logiciels) convenable en termes de rapport qualité/prix et de pérennité.

Le client de l’informatique, ou " maître d’ouvrage ", c’est la personne morale (entreprise, direction) qui réalise des tâches opérationnelles ou prépare des décisions. L’informatique est pour lui un outil. Il exprime ses besoins en formulant une demande; mais toute demande résulte de la rencontre d’un besoin et de la connaissance d’une offre.

Si quelqu’un veut se faire construire une maison, il faut qu’un architecte l’aide à traduire son besoin en demande pertinente. S’il s’agit d’un système d’information, l’" architecte " s’appelle " assistant à maître d’ouvrage (2)". Si seul le client est porteur légitime de son besoin, l’expression de ce besoin nécessite l’aide d’un spécialiste.

Processus

Le salarié d'hier était un ouvrier devant sa machine ; le salarié d'aujourd'hui est un employé devant son micro-ordinateur. Les entreprises s’organisent autour d'un système d’information réparti sur des micro-ordinateurs communiquant via le réseau. Le travail, devenu immatériel, se résume à une manipulation de concepts et d’informations, les " produits " de ce travail n'étant que les supports de ces information (plans, rapports, notices etc.). Bien sûr des biens matériels sont finalement produits, mais avec peu de travail physique.

Les NTIC bousculent la conception de la valeur. Elle réside non dans les produits stockés ou immobilisés, mais dans leur conception. La part du capital fixe dans l'actif de l’entreprise décroît. Son actif essentiel est désormais d'une part le stock des compétences, d'autre part son aptitude à en organiser la mise en œuvre (4). On peut distinguer dans ces compétences une gestion du stock (formation et accumulation) et du flux (mise en œuvre dans l'action).

Ce flux, c'est celui des processus qui concourent aux décisions. Le bon décideur n'est pas celui qui s'attache à prendre en toutes circonstances la meilleure décision (ambition surhumaine), mais celui qui prend soin de mettre en place les processus minimisant le risque d'erreur. L’organisation des processus, c’est le réseau de l’entreprise (5). L’entreprise qui s’organise pour parcourir efficacement ses processus devient l’" entreprise-réseau " dans laquelle une organisation transverse permet aux personnes compétentes de coopérer sans perte de temps. Les processus s'organisent en " workflows " reliant les expertises concourant à la décision. Les " workflows " permettent de baliser les circuits, maîtriser les délais, publier les avis et connaître l'état de la procédure. Certains voient dans le " workflow " l'innovation la plus importante dans le domaine des systèmes d'information (6). La hiérarchie intervient a posteriori sur leur définition et leur évolution, et délègue la responsabilité opérationnelle de leur mise en œuvre.

Culture des usages

Cependant les NTIC ont quelques effets pervers :

• la mémoire de l'ordinateur, exhaustive, ne comporte pas le mécanisme d'oubli sélectif qui facilite le travail de synthèse de l’esprit humain. Tout garder en mémoire, c'est ne rien comprendre.
• si les traitements de texte, tableurs etc. aident à traiter vite des problèmes urgents, ils encouragent un activisme qui s'oppose à la maturation de la pensée et au choix des priorités.
• la messagerie et surtout les forums supposent un savoir-vivre des utilisateurs, (la " Netiquette "). Ils doivent prendre garde au ton de leurs messages ; si ceux-ci sont écrits trop vite, ils seront jugés agressifs et les relations entre collègues en pâtiront.

Une culture des usages doit accompagner la mise en œuvre de ces outils. On retrouve ici des préceptes classiques : il faut prendre le temps de réfléchir, trier et élaguer l'information, prendre du recul pour maîtriser son activité... Les règles dégagées par les humanistes de la Renaissance gardent toute leur fraîcheur.

Souvent ces principes sont ignorés (7). L’utilisation des NTIC retient rarement l'attention des responsables ; elle est laissée à l'initiative d'équipes qui se livrent, dans la confusion, à d'épuisantes luttes pour des miettes de pouvoir. Les directions informatiques ont d’ailleurs la nostalgie de l'époque où de gros systèmes irriguaient des terminaux " bêtes ", et où il leur était facile d'imposer leur langage à l'entreprise. Enfin, la bureautique reste marquée par un esprit de bricolage incompatible avec toute ambition en matière de système d'information.

Les entreprises ne tirent pas encore les conséquences du fait que le micro-ordinateur communiquant devient le poste de travail de chacun. Elles confient les tâches d'organisation à des cabinets qui vendent des méthodologies conservatrices, et la bureautique à des techniciens mal payés.

Il en résulte que la mémoire de l'entreprise est négligée : pas de gestion de la documentation ni des archives, donc pas d’accumulation de l'expérience technique ou commerciale ; les nouveaux doivent passer par un long apprentissage. La documentation d'une équipe n'est pas utilisable par une autre, et sur chaque site on ignore les produits fabriqués ailleurs : il est difficile de faire travailler ensemble des entités distantes. Le partage des rôles entre partenaires d'un consortium fait l'objet de négociations répétées parce que le texte du contrat est difficilement accessible, etc.

Les personnes compétentes ne sont pas consultées lors de la préparation des décisions. Le dossier va d'un bureau à l'autre, s'attarde dans une pile. Les délais sont aléatoires. Il faut une longue recherche pour savoir où en est une affaire et la débloquer.

Ces errements n'ont rien de nouveau. On a déjà vu cela dans l’usage des télécommunications :

- télécopieurs longtemps réservés aux secrétariats des directeurs ;

- compléments du service téléphonique souvent ignorés (8) ;

- entreprises négligeant les économies qu’elles feraient sur leurs réseaux multisites si elles observaient le trafic, optimisaient leur architecture et choisissaient des PABX compatibles ;

- messageries souvent inutilisées ou débordant de messages parasitaires ;

- câblages souvent inextricables, non documentés, redondants ;

- " méthodes " d'expérimentation inadéquates (" nous avons essayé et ça ne marche pas " signifie :  "  nous avons fait un essai rapide sans résultat probant ", et non " nous avons fait une expérience en utilisant un protocole tenant compte des effets taille et réseau, et le résultat est clairement négatif " ;

- accueil téléphonique rébarbatif (9) ;

- etc.

Si les NTIC relèvent de techniques complexes, et si leur conception a nécessité une réflexion d'excellent niveau, leur mise en œuvre réclame de la modestie, du bon sens, une énergie persévérante et du courage.

Transition vers les processus (10)

Les systèmes d’information s’organisent désormais autour des processus de l’entreprise. Pour illustrer ce changement, nous décrirons deux " modèles " nommés M₁ et M₂. Dans M₁, le système d’information se construit autour des applications informatiques. Dans M₂, il se construit autour des processus des métiers. Le rôle de l’informatique change lors du passage de M₁ à M₂ (11) .

Modèle M₁ : les applications

Une application, c’est une suite de traitements appliqués sur des données initiales (" input ") pour fournir un résultat (" output "). Les données initiales sont soit introduites dans l’application par saisie ou comptage automatique, soit issues d’autres applications. Les traitements sont soit des additions permettant de mesurer des agrégats à partir de données détaillées, soit des calculs plus spécifiques (12).

Le fondement d’une application, tel que le définit Merise, réside dans deux modèles : le modèle conceptuel de données comprend les définitions sémantique (13) et technique (14) des données ; le modèle applicatif décrit les traitements.

Nous allons décrire deux scénarios de mise en œuvre du modèle M1 : le premier, " rose ", montre comment les choses sont censées se passer. Le second, " gris ", montre comment elles se passent souvent.

Scénario " rose "

L’application limite la saisie au strict nécessaire, automatise les traitements, et affiche sur l’écran (ou imprime sur papier) les résultats dont l’utilisateur a besoin. La récupération des données issues d’autres applications sera 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 sous une double contrainte de qualité (15) et d’économie. Il répartit ainsi les ressources (mémoire, puissance de calcul, débit des liaisons télécoms) et définit des applications intermédiaires. La cohérence des applications est alors réalisé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 lorsque les besoins changeront.

Scénario " gris "

L’urgence, l’insouciance, l’optimisme, le cloisonnement de l’organisation poussent à concevoir et développer les applications au coup par coup, selon l’arrivée des demandes, sans que la relation avec les autres applications soit maîtrisée ; des données de référence (16) sont redéfinies 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’utilisateur sont hétéroclites (touches de fonction et codages spécifiques à chaque application). La " gestion de configuration " (documentation des versions successives d’une application) est laissée à la bonne volonté des chefs de lignes de produits, et certains la négligent. Beaucoup d’incidents restent inexpliqués.

L’entreprise, pour sa part, considère l’informatique comme un centre de coût, non comme un centre d’investissement au service des métiers. La pression budgétaire est exercée de façon mécanique et aveugle par une " enveloppe informatique ". Une méfiance se crée entre les informaticiens et l’entreprise. Les engagements sur les coûts et délais ne sont jamais tenus. L’informatique se divise en petites baronnies jalouses de leur indépendance.

Modèle M₂ : les processus

Le terme de " processus " désigne l’enchaînement des tâches réalisées pour remplir une fonction de l’entreprise. Ces tâches sont soit mentales (perception, jugement, décision) soit physiques (imprimer un billet, le donner à un client, réaliser une opération de maintenance), les tâches mentales préparant les tâches physiques (17). Le système d’information vise à assister l’utilisateur dans la réalisation des tâches mentales liées aux processus.

Formaliser un processus conduit à l’équiper d’un " workflow ", c’est-à-dire d’une documentation explicite des tâches et de leurs relations :

• préciser les interfaces nécessaires à chaque activité (on regroupe sur le même écran les plages de consultation et de saisie nécessaires à une activité, ce qui évite à l’utilisateur 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 (lorsque l’utilisateur tape sur la touche " valider " qui marque la fin de son travail, il n’a pas à chercher à qui envoyer le résultat).

Le délai de réalisation d’une tâche est surveillé par un " timer " qui prévient l’utilisateur en cas de dépassement, ou qui reroute le message vers un autre utilisateur(18).

Exemple d’interface utilisateur (19)

Modéliser un processus, c’est décrire la succession des tâches qui concourent à une mission : 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 routages de ses messages vers les autres acteurs, les compteurs qui permettent au responsable du processus de contrôler la qualité.

La réalisation physique des tâches est décrite dans le modèle, puisqu’il la documente, mais elle 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 relève de l’ " assisté par ordinateur ", non de l’automatisation ; il aide l’utilisateur sans se substituer à lui, même s’il automatise des tâches que l’on faisait auparavant à la main.

Représentation du processus

Un processus se décrit sous la forme d’un graphe. Les nœuds représentent les tâches élémentaires (" activités "), les arcs représentent les messages émis à la fin d’une tâche, pour lancer les tâches suivantes. Il est commode de donner à ce graphe la forme circulaire qui marque que le processus est déclenché par un fait extérieur (réception d’une commande, d’une lettre de réclamation, franchissement du délai de maintenance d’un équipement) auquel le processus répond par une action sur l’extérieur (livraison, lettre, opération de maintenance). Il convient de s’assurer que cette réponse a lieu dans un délai et sous une forme convenable : c’est le contrôle du bouclage du processus.

Il faut souvent introduire d’autres compteurs (volume, délai, valeur etc.). En effet, la formalisation du processus suscite une organisation impliquant une délégation de responsabilité aux personnes qui réalisent les tâches. Dès lors l’intervention de l’encadrement ne se fonde plus sur l’approbation des actes un par un, mais sur un contrôle statistique a posteriori et sur la diffusion de consignes nouvelles si des dysfonctionnements apparaissent ou si l’on veut faire évoluer le processus.

La réalisation d’un processus suppose souvent des sous-processus fournissant chacun des " livrables " intermédiaires (exemple : expertise fournie lors de l’instruction d’une demande d’autorisation d’investissement).

Le processus a une existence de facto, avant toute description. Mais un processus qui n’a pas été pensé présente souvent des défauts. Par exemple il ne boucle pas : la succession des tâches se poursuit sans que l’on vérifie qu’il a été répondu à chaque événement extérieur, et le risque existe que le processus " se perde dans les sables " (c’est le cas lorsqu’une lettre de client passe de mains en mains, sans que personne ne contrôle le délai de réponse : on finit par renoncer à lui répondre lorsque le délai décent a été dépassé).

Les fonctions de la hiérarchie intermédiaire (transmission des consignes vers le bas et des rapports vers le haut) sont remplacées par le workflow, ses compteurs et l’édition semi automatique des comptes rendus. Le nombre des niveaux hiérarchiques est donc réduit, la communication entre " base " et " sommet " devient plus facile. Par ailleurs, l’approche par les processus est souvent " qualifiante ". La transparence, la diffusion de l’information suppriment l’opacité des procédures, la rétention de l’information, les mille abus que ces pratiques permettent.

Processus et objets

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. Chaque utilisateur va consulter ou saisir quelques données, déclencher un nombre limité de traitements : ceci conduit très naturellement vers la programmation orientée objet.

Le langage UML (20), qui fédère les langages de modélisation en matière d’approche objet, fournit les documents nécessaires pour décrire les activités (" use cases  " selon le vocabulaire de Jacobson), les classes (" diagrammes de classes ") et la succession des opérations (" diagrammes de séquences "). On construit ainsi le " modèle complet " 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 les compteurs utilisés à des fins de contrôle.

Le modèle complet des processus est plus précis que les spécifications qui étaient fournies à l’informatique dans le modèle M₁. Il indique sans ambiguïté ce que l’utilisateur veut faire, et aide à découper le développement en petits modules, les classes, clairement 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 sont utiles à plusieurs acteurs ou que l’on peut satisfaire les besoins de plusieurs acteurs en construisant des classes dont la forme logique est identique ou analogue (héritage, polymorphisme). Ces analogies font apparaître des êtres sémantiques nouveaux concrétisant des concepts inédits. Les langages de développement " orientés objet " exploitent ces possibilités qui allègent le développement au bénéfice de la conception. Ils réduisent les coûts de maintenance et facilitent l’évolution du système d’information.

Passage de M₁ à M₂

Le passage de M₁ à M₂ suppose un changement, tant pour le système d’information que pour l’organisation.

La responsabilité du système d’information passe de l’informatique, qui la détenait traditionnellement, aux métiers qui définissent son contenu fonctionnel.

L’informatique cesse d’être un centre de coûts et devient centre d’investissement au service des métiers. L’entreprise renonce à la notion d’ " enveloppe informatique ".

Le soutien aux utilisateurs devient l’activité prioritaire de l’informatique, alors qu’il confine aujourd’hui souvent au bizutage. Les éléments essentiels du système d’information sont les processus et les objets, non plus les applications.

Ces changements de priorités auront des conséquences sur la façon dont les informaticiens perçoivent leur rôle.

Transition de l’organisation

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

 Il ne faut pas sous-estimer les difficultés de cette évolution. Ceux qui pratiquent la rétention d’information, qui se protègent sous l’opacité des procédures, ne sont pas pour autant de mauvaises gens : ils se sont adaptés à l’entreprise et se protègent contre son comportement spontané. Passer de M₁ à M₂ suppose une traversée du désert pendant laquelle ils ne bénéficieront plus des protections que comporte M₁ et n’auront pas encore atteint l’équilibre que permet M₂.

L’exhortation morale serait ici dérisoire : cet effort n’est raisonnable que si chacun comprend qu’il peut y gagner personnellement. La communication, au sens médiatique du terme, est un épisode crucial de la migration. Il faut susciter l’espoir, éveiller l’intuition, avant de chercher à régler les problèmes techniques : ils se régleront souvent d’eux-mêmes (ou plutôt ils seront réglés dans la foulée) si l’espoir est présent.

Processus et système d’information

Dans M₁, la définition des applications reposait sur l’" expression de besoins ". Elle suppose une interprétation du travail à faire par les utilisateurs, mais cette interprétation n’est pas nécessairement explicite et reste donc abstraite. Rien ne garantit qu’elle permettra un bon contrôle du processus puisqu’elle n’est pas construite pour cette fin.

Si l’on considère les processus, on ne part pas de la question " quels sont les résultats qu’il me faut pour travailler ", mais de la question " comment est-ce que je travaille " : on découvre alors que tel processus ne boucle pas, ou n’est pas contrôlable, ou comporte une redondance (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). Structurer 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. C’en est fini des rétentions d’information et de signature qui constituaient autant de monnaies d’échange.

Système d’information et système informatique

Le système d’information est essentiellement sémantique et fonctionnel ; il est défini par un " modèle complet  ", qui fait abstraction des moyens techniques. Le système informatique, par contre, organise ces moyens ; il choisit les plates-formes, langages, interfaces, architectures (centralisée, client serveur à deux ou trois niveaux), la localisation des traitements et mémoires, les niveaux de conservation des données. Il repose sur une expertise attentive à la diversité des outils du marché, aux innovations, à la pérennité des solutions. La maîtrise d’ouvrage doit se doter d’une expertise spécifique, fonctionnelle, garantissant la pertinence des demandes en regard des exigences du métier.

Dans M₁, 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 ; cependant la solidarité des applications, et donc du système d’information, se concrétisait au sein de l’informatique. La tentation était alors grande de confier à celle-ci davantage qu’une mission de maîtrise d’œuvre, et d’en faire le concepteur du système d’information se substituant aux utilisateurs pour définir leurs besoins.

Dans M₂, la séparation devient claire. A l’un la responsabilité du modèle complet, à l’autre celle de la solution technique. Cette répartition n’interdit pas le dialogue : la maîtrise d’ouvrage peut s’intéresser aux solutions techniques, le maître d’œuvre avoir des idées sur ce qui est utile au plan fonctionnel. Cependant à ce dialogue succède la décision, et alors chacun doit prendre ses responsabilités propres.