Si on les regarde dans leurs grandes lignes, les systèmes d'informations des grandes entreprises possèdent tous les mASmes aspects. Outre leur omniprésence dans les processus de travail, ils se présentent comme un ensemble d'applications de gestion, ce qu'on appelle le plus souvent des applicatifs, reliés entre eux autour d'une architecture particulière et généralement complexe. Cette architecture est comme la -machinerie interne- du système car c'est elle qui régule la communication entre les divers applicatifs et les équipes qui les servent.
Au-delA  de ces éléments, et du point de vue qui nous occupe, tous possèdent deux caractéristiques essentielles :
» ils sont organisés autour de modèles de données auto-centrés, ce qui signifie ici que leurs données sont définies du point de vue de l'entreprise (cf. ci-après) ;
» et tous ont des difficultés A  intégrer les outils de communication professionnelle, au point que, bien souvent, les projets de soutien A  ce type de communication se sont déroulés A  l'extérieur des systèmes d'information classiques.
Cette situation est importante car au-delA  des questions techniques l'enjeu, ici, est la structure de gestion du SI - que nous appellerons son pilotage politique - et la manière dont il a perA§u le développement des nouveaux outils de communication.

La rationalisation du travail, préalable A  l'informatisation
Pour la comprendre, il faut se départir de l'illusion technologique, assez fréquente sur ces sujets, qui veut que les systèmes d'information (SI) aient été pensés en tant que tels A  leur origine, et souvent A  partir de zéro.
Cette illusion n'est qu'un effet de re-construction intellectuelle qui nous fait imaginer que les applicatifs ont été conA§us globalement. En fait, les SI des grandes entreprises sont d'abord le produit de leur propre histoire. Ils n'ont été construits que progressivement, par déformations successives en quelque sorte. Mais A  chaque avancée, et lA  est le point important, ces -déformations- se sont réalisées en relation au travail opérationnel, et le plus souvent, dans la perspective de rationaliser une situation de travail donnée. Il s'agit mASme d'une constante de la construction de tous les systèmes d'information, qui n'est pas sans rappeler le monde industriel : leur finalité a presque toujours été l'économie de travail humain et, pour l'essentiel, de travail intellectuel.
Cette situation s'imagine aisément ; mais elle possède une importante contrepartie. Car A  partir du moment où un applicatif se conA§oit dans de telles conditions, il est fortement dépendant de l'organisation originale du travail. En fait, un applicatif ne se construit que rarement sur des situations de travail mouvantes mASme si, dans l'idéal, il pourrait y AStre très utile. Il s'appuie presque toujours sur une rationalisation préalable du travail qui lui -prépare le terrain-. Pour le dire précisément, au départ de toute élution du système d'information, se trouve une organisation structurée en procédures récurrentes et claires, A  l'image de celles que nous venons de discuter au chapitre précédent. Et si l'on y réfléchit, l'ensemble du pilotage politique des SI va découler de cette situation.

De la procédure A  l'applicatif

Prenons l'exemple, pour illustrer ce point, de cette procédure de calcul de coefficient de risque dans une comnie d'assurance, que nous reproduisons ici de faA§on ultra-simplifiée : calculer le coefficient de risque en fonction de l'age du titulaire, de son habitation et de la catégorie de son véhicule.
Cette procédure commande une action humaine que l'on imagine assez bien : il s'agit d'un calcul, généralement sur des abaques joints A  la procédure, qui mixte des critères propres au titulaire du contrat et des données géographiques (on calcule une partie du risque A  partir des trajets usuels d'un titulaire et ici son lieu d'habitation est sensé les révéler). Et, a priori - c'est ainsi que des générations d'agents l'ont compris - ce calcul s'effectuera globalement, par un seul acteur, qui en général est en position de back-office d'une agence. Cependant, si on l'étudié de près, on verra que cette procédure se décompose en deux éléments distincts :
- Une partie du travail est de pure logique : ce sont les termes du calcul proprement dit, dont -l'économie interne- est indépendante des données de départ ;
- Une autre partie renie A  la prise en compte des paramètres, les -données-, qui sont généralement fournies directement par le client ou saisies sur un formulaire dans un processus de travail.
On le sait, un applicatif informatique simule les raisonnements logiques. Il aura donc les moyens d'automatiser la première partie du travail de l'agent, qui se concentrera de ce fait sur les seules données. Progressivement - car il faut imaginer que le calcul ne sera automatisé qu'au travers de plusieurs versions de l'outil - tous les éléments logiques nt AStre -intégrés- A  la machine pour ne laisser A  l'agent que l'alimentation du logiciel, lequel proposera automatiquement au client le contrat - et y compris effectuera certaines démarches administratives comme le courrier.

Les deux fonctions de pilotage d'un Système d'information
En généralisant cet exemple, on it alors que les applicatifs de gestion ne se composent en fait que de deux types d'éléments.
1. Un enchainement logique d'opérations, sensées AStre identiques quelles que soient les données, qui forment le cœur des logiciels et qui remplacent de facto les anciennes procédures.
L'enjeu majeur sera naturellement d'en assurer la cohérence et l'élution, aussi bien sur le des fonctionnalités que de la technologie pure, car les applicatifs sont destinés A  AStre servis par de multiples points d'entrée. Ce travail - aussi précis que technique -sera celui du maitre d'oeuvre des SI, c'est-A -dire le plus souvent une Direction du système d'information (DSI). Disons-le d'entrée, ce sera pendant longtemps son principal souci si tant est que cette situation soit dépassée.

Notions de base d'analyse d'un SI

Un système d'information n'est qu'un ensemble d'applicatifs tels que nous les ans décrits. Ces applicatifs s'appuient sur une architecture technique qui permet A  de nombreux utilisateurs de les servir simultanément. Mais cette architecture n 'est pas dite -en réseau- car le système est géré par quelques ordinateurs centraux (sur le modèle client-serveur, le plus souvent).
On parle d'architecture fonctionnelle pour désigner l'ensemble des applicatifs lorsqu 'on les regarde A  partir de leurs finalités métier. C'est la fonction stratégique d'un SI.
L'urbanisme désigne la cohérence interne des applicatifs, c 'est-A -dire le point de vue de la MOE sur cette architecture, généralement plus facile A  maitriser.
Les ERP (executive resource ning) sont des applicatifs génériques (progiciels) batis autour d'une architecture standard dont on escompte qu'ils permettront de simplifier l'urbanisme des SI des grands groupes.
Les modèles de données sont les modèles de paramètres qui serviront d'entrée/sortie aux applicatifs de gestion. Eléments fondamentaux des SI - mASme s'ils ne font pas partie de la fonction la plus valorisée - ils sont au cœur de la maitrise d'un SI par une direction métier. Dans certaines entreprises, sont apparus des propriétaires de données - cadres dont la mission est de veiller A  la cohérence de l'usage d'un paramètre par un SI. Ces propriétaires peuvent s'appuyer sur des référentiels de données qui sont sensés en donner une définition explicite. Le lecteur notera que ces notions sont loin d'AStre généralisables aux nouveaux outils de communication, ce qui signale une hétérogénéité foncière des deux systèmes.

2. Et des bases de données qui se situent en entrée et en sortie de chaque applicatif et seront de ce fait le lieu essentiel d'interrela-tion entre l'homme et la machine.
L'enjeu majeur sera alors de lier ce travail sur les données aux finalités du métier, car l'organisation du travail dépend de cette relation. Il s'agit d'un enjeu dont l'importance sera comprise plus tardivement et qui générera la position de maitrise d'ouvrage -métier-, distincte de la maitrise d'œuvre et se chargera de gérer cette dimension, en s'efforA§ant de la relier A  la stratégie de l'entreprise (cf. sur ce point notre encadré chapitre 5).

Problèmes actuels du pilotage des systèmes d'information

Un simple exemple, on le it, nous permet de situer avec précision les fonctions politiques de contrôle et de construction des systèmes d'information. Cela veut dire que cette gestion est simple dans son principe, mais aussi que les difficultés - très réelles -viennent de la quantité d'applicatifs qui nt AStre élaborés et de la complexité des situations qui en résultera. Une quantité souvent impressionnante, au demeurant, comme dans cette entreprise qui a compté près d'une centaine d'applicatifs structurant la chaine de travail de son cœur de métier. Et pour ce qui nous concerne, s'en sont déduits deux points majeurs qui expliquent le peu de souplesse actuel des SI vis-A -vis des nouveaux outils de communication :
L'incohérence structurelle entre les divers applicatifs qui provient, in fine, du point de vue restreint avec lequel chaque applicatif a été conA§u.
Cette difficulté est au cœur des préoccupations des maitrises d'œuvre. Elle explique que les DSI se soient en général polarisées sur un contrôle très strict des élutions fonctionnelles, notamment après l'échec des projets - que l'on a qualifiés de pharaoniques - de refonte globale des SI (il y a une grosse dizaine d'années environ). C'est ce besoin de contrôle - dont la résorption est l'enjeu des travaux -d'urbanisme- - qui explique la longue réticence des DSI A  toute idée de système d'information souple et les succès récurrents des ERP.
La mauvaise orientation -logique- des données, dont le référentiel a été construit d'un point de vue interne A  l'entreprise et se traduit par un éclatement de la vision de l'environnement de l'entreprise donnée par le SI.
Ce point ne s'est révélé que sur le tard, et pour tout dire les entreprises ont eu du mal A  le comprendre. Il signifie que les données n'ont pas forcément le mASme sens pour deux acteurs différents et donc pour le SI (cf. notre explication dans le chapitre 6). Ainsi l'adresse de notre exemple ne vise-t-elle pas l'habitation en tant que telle du sociétaire mais le lieu géographique et son rapport A  la circulation. La complexification aidant, il se crée tout un processus d'éclatement de l'identité des objets désignés par un SI, A  commencer par les clients qui peuvent, par exemple, AStre traités de faA§on spécifique pour chaque produit.
C'est de cette ambiguïté que sont nés les outils dits de CRM. dont le projet est de réunifier la vision -informatique- d'un client A  partir de ces informations éclatées, et, on le verra dans l'encadré ci-après, des diverses positions de travail en contact avec le client.

Applicatifs de gestion et outils de connaissance

De telles difficultés, répétons-le, sont loin d'AStre insurmonles. Elles pourraient AStre en partie levées - et mASme plutôt facilement - en s'appuyant sur des outils plus souples, comme les outils de communication en réseau : les workflows, par exemple, sont de puissants outils de transversalité. Et la souplesse de leur usage a pour effet, A  terme, de renforcer la cohésion interne des applicatifs qui leur sont liés. Quant aux outils de groupware, il est clair qu'ils pourraient aisément soutenir la logique CRM : il est désormais facile, grace A  eux, de structurer un débat entre différents acteurs concernés par un mASme objet (ici A  propos d'un client). L'expérience rapportée dans l'encadré est assez explicite sur ce point.

Prémisses du groupware
Un travail d'enquASte pour une structure commerciale -high lech- sur un marche de grandes entreprises s est déroulé en 97. Répondant a la question -générique- des besoins d'information des équipes, l'enquASte A  mis le doigt sur l'existence d'un besoin spécifique A  certaines équipes commerciales, porté, pour l'essentiel, par les ingénieurs en position de soutien (dit technico-commerciaux). Ces ingénieurs se disaient confrontés A  des questions déplus en plus fréquentes de la part de leurs clients, et mASme A  des dialogues techniques exigeants. Ils exprimaient de ce fait un besoin croissant de connaissances sur le contexte des offres, ainsi que la nécessité d'élir des discussions restreintes ' en cercle fermé - sur ces enjeux :
» A  l'intérieur des équipes commerciales sur la situation de leur client,

» et entre professionnels.

Ces personnes distinguaient ces usages potentiels de ceux des bases d'information -en ligne- perA§ues comme utiles, mais trop générales et peu adaptées A  ce besoin précis (cf. ci-après pour la relation aux Intranets).
L'enquASte a conclu A  la nécessité d'outils de groupware spécifiques aux équipes clients, en arguant de la nécessité croissante de dialogues -en cercles restreints- et de l'inadaptation des outils de gestion déjA  installés. Ceux-ci permettaient bien une interaction, mais au travers de champs préformatés qui n'autorisaient que des échanges d'information factuels et mal fiabilisés. Elle proposait de les compléter par des référentiels d'offre pour faciliter les dialogues. Elle pointait enfin la nécessité d'animer ces dialogues A  partir d'un point de vue marketing. Observations personnelles.

Néanmoins, force est de constater que les directions en charge des systèmes d'information ont été plutôt réticentes face A  l'utilisation de ces nouveaux outils. Une résistance plus larvée qu'affirmée, d'ailleurs, car on a assez souvent créé des structures dédiées aux -outils bureautiques- dans les grandes DSI. Cependant, ces structures sont généralement restées sans grand budget ni grand pouir, ce que l'on justifiait au nom d'arguments technologiques assez sérieux (la nécessaire homogénéité des architectures de réseau) ou d'arguments économiques qui l'étaient peut AStre moins (la renilité aléatoire de ce qui apparaissait d'abord comme un investissement).
Quoi qu'il en soit, et que l'on se situe du côté des MOE ou des MOA., les années passées ont été marquées par une extrASme difficulté d'intégrer les logiques de partage de connaissances. C'est la raison pour laquelle nombre de Directions Générales ont du se résigner A  créer des structures autonomes - formellement indépendantes des directions-pilotes du SI ' afin de rattraper un retard que l'on yait croissant sur ces outils. La démarche a été très fréquente A  partir de l'explosion des Intranets.
Au-delA , ce phénomène explique qu'un espace important ait été créé dans les entreprises pour une approche différente des outils d'information, ouverte aux influences extérieures A  l'entreprise et surtout autonome par rapport aux -réglementations- du pilotage politique du SI (d'aucuns qualifieraient cette approche de -sauvage-). Dans cet espace, une demande croissante dans les équipes de travail - de plus en plus soumises aux enjeux de connaissance - a rencontré une offre extérieure A  l'univers classique des systèmes d'informations, et pour cela plus proche des enjeux managériaux.
C'est dans cet espace que se sont insérés, ire mASme que se sont forgés les courants de pensée qui se réclameront du Knowledge Management. Nous aborderons ici les deux principaux, en les classant d'après leur origine : l'intelligence artificielle d'une part et le courant de l'informatique en réseau d'autre part.