GROUPWARE - 3kernels.free.fr3kernels.free.fr/divers/support/ipi/divers/groupware.pdf · ©Lotus Development Corporation (1995) 9.2.1 Les applications Notes 40 9.2.1.1 Les différents

Groupware

© Lotus Development Corporation (1995) groupware.doc 17/07/01 15:07 version 12

GROUPWARE

A withe paper on

Communication, Collaboration and Coordination

Auteur : Lotus Development Corporation

© Lotus Development Corporation (1995)

Cette page est laissée intentionnellement blanche.

Groupware


Table des matières 1 Introduction....................................................................................................................1

1.1 En résumé 2 2 Définition du groupware................................................................................................5 3 Communication .............................................................................................................8

3.1 Messagerie électronique : une technologie de communication 8 3.2 Stockage des messages 8 3.3 Conclusions 10

4 Collaboration .................................................................................................................11 4.1 Bases de données partagées : une technologie favorisant la collaboration 11

5 Les applications du travail collaboratif..........................................................................13 5.1 Forum électronique 13 5.2 Exploitation des bases de données partagées pour d'autres a plications 13 5.3 Kiosques électroniques 14 5.4 La nature passive des bases de données partagées 14

6 Le World Wide Web : un outil de travail en collaboration ...........................................16 6.1 L'infrastructure du Web 16

6.1.1 Première phase : Publication d'informations. 17 6.1.2 Deuxième phase : Formulaires à champs. 18 6.1.3 Troisième phase : Langages de programmation. 18 6.1.4 Quatrième phase : Pages interactives dynamiques. 18

6.2 Contraintes du Web 18 6.3 conclusions 19

7 Quatre générations de messagerie..................................................................................22 7.1 Messagerie et groupware intégrés 22 7.2 Modèle de workflow fondé sur la messagerie 23 7.3 Modèle de workflow fondé sur une base de données partagées 23 7.4 Un modèle intégré 24 7.5 Modèle élargi de transaction 24 7.6 Cadre de développement d'applications 25 7.7 conclusions 26

8 Architecture du groupware ............................................................................................27 8.1 Modèle d'information : la base objets du groupware 27 8.2 Technologies de distribution 28

8.2.1 Routage asynchrone 28 8.2.2 Réplication 29

8.3 Environnement de développement d'applications 30 8.4 Langages et outils de programmation 31 8.5 Développement par l'utilisateur final 33 8.6 Intégration avec des sources de données externes 34 8.7 Sécurité 35

8.7.1 Authentification 35 8.7.2 Contrôle d'accès 36 8.7.3 Chiffrement au niveau du champ et du document 36 8.7.4 Signatures numériques 36

8.8 Carnets d'adresses 36 9 Quelques mots sur Lotus Corp. .....................................................................................39

9.1 Notes Domino en quelques mots 39 9.2 Présentation des applications Notes 40


9.2.1 Les applications Notes 40 9.2.1.1 Les différents types d'application Notes 40 9.2.1.2 Flux et groupes de travail 41

9.2.2 Notes et les bases de données relationnelles 41 9.2.3 Notes et Internet 42 9.2.4 Définition des applications Notes 43

9.2.4.1 Les circonstances où Notes ne convient pas 43 9.2.4.2 Applications et bases de documents Notes 43

9.3 Conception d'une base de documents Notes 43 9.3.1 Composants fondamentaux d'une base de documents Notes 43

9.3.1.1 Eléments conceptuels fondamentaux 43 9.3.1.2 Eléments de conception pouvant être créés par un utilisateur 44 9.3.1.3 Eléments pouvant être créés par le développeur 44

9.3.2 Création d'une base Notes 44 9.3.2.1 Etapes de construction et de déploiement d'une application 45 9.3.2.2 Etapes de construction et de déploiement d'une application... 45 9.3.2.3 Création d'une base Notes. 46

© Lotus Development Corporation (1995) groupware.doc 17/07/01 15:07 version 12

1


1 Introduction Le savoir constitue le seul actif durable de toute institution. C'est donc de sa capacité à le collecter et à le gérer que dépendent la survie et la réussite d'une organisation, quelle que soit sa taille. Nous avons assisté à la naissance d'une classe de logiciels, le «groupware». Cette importante technologie permet aux sociétés de créer, de partager et d'exploiter leur savoir. Au fur et à mesure que les utilisateurs exigent une large panoplie de services de groupware, les responsables des systèmes informatiques se trouvent confrontés au défi posé par la mise en oeuvre de l'infrastructure correspondante. En réalité, toute implantation de groupware réussie dépend à la fois de la disponibilité des technologies nécessaires et de l'engagement de la part des responsables informatiques d'implanter l'infrastructure système et organisationnelle voulue. Cette infrastructure devra être développée selon un planning adapté à la demande à venir des utilisateurs. Très utilisé, mais mal compris, le terme groupware est souvent source de confusion et de scepticisme. Ce regrettable état de fait traduit deux tendances de fond. D'abord, les fournisseurs, les utilisateurs et les observateurs ont eu tendance, spontanément, à considérer le groupware comme la somme de ses applications, accordant peu d'importance à la technologie et à l'infrastructure appropriées ou optimales. Il a donc été difficile de se faire une image cohérente de la technologie du groupware, en se fondant sur des applications aussi disparates que le courrier électronique, la gestion et la planification de groupe, le routage de formulaires, l'automatisation du workflow, les forums électroniques, les «bulletin boards» et les systèmes de vidéoconférence, pour ne citer que ceuxlà. Bien souvent, des applications qui n' avaient jamais été conçues pour le groupware ont été modifiées ou utilisées au-delà du cadre de leur conception pour répondre à un besoin de l'entreprise. Ensuite, tout débat sur le groupware tend à se focaliser sur des technologies spécifiques dont le modèle de base est assez réducteur. Les éditeurs ont généralement bâti des produits sur la technologie qu'ils connaissaient bien. Il n'est donc pas étonnant que ceux dont les produits font de la communication diffusant de l'information dans une organisation voient dans la messagerie la technologie de base du groupware. De même, les fournisseurs de produits de collaboration pour le partage d'informations et la construction d'une compréhension partagée tendent à considérer que les forums électroniques et le partage des bases de données constituent le noyau du groupware. Enfin, ceux dont les produits ont pour cible d'aider les personnes et les groupes dans la coordination de différentes tâches complexes (par ex. délégation, approbations, etc.), sont portés à considérer comme le sine qua non du groupware les outils de développement d'applications pour l'automatisation des tâches et du workflow. En réalité, une infrastructure complète de groupware ne se limite pas à gérer ces trois modes de travail en groupe, mais les met en synergie, produisant un ensemble plus puissant que la simple somme de ses éléments. Cette « Bible » examine les trois dimensions du groupware, communication, collaboration et coordination, présente les différentes technologies qui ont servi à leur mise en oeuvre : messagerie, bases de données partagées, automatisation du workflow et examine dans quelles conditions chacun de ces modèles, poussé au-delà de ses véritables capacités, s'avère insuffisant. Elle montre ensuite qu'une infrastructure complète de groupware se situe à la convergence de ces technologies par ailleurs totalement distinctes.

2 Groupware


Ce débat sur l'infrastructure vire parfois au dogmatisme et, bien souvent, à la «pureté architecturale», au risque de passer à côté des réalités, à savoir l'usage que fait effectivement chaque individu, groupe ou organisation de ces applications, pour la collecte, la gestion et l'exploitation du savoir de l'entreprise. En fait, la courte histoire des applications de groupware montre que ce sont les utilisateurs eux-mêmes qui font progresser une technologie, en l'adaptant à des besoins différents de ceux pour lesquels elle a été conçue. Nous nous efforçons dans ce papier de pondérer la rigueur architecturale par une appréciation du fonctionnement concret des groupes. Le fait que les utilisateurs trouvent par eux-mêmes des façons inédites d'exploiter la technologie est un des éléments les plus marquants des infrastructures de groupware. Celles-ci doivent donc être assez souples pour s' adapter aux besoins spécifiques des utilisateurs at non pas leur imposer des solutions prédéfinies. Il apparaît donc une synergie naturelle entre communication, collaboration et coordination, dans l'évolution des groupes et de la technologie qui les sous-tend. Plus particulièrement, les technologies de la messagerie et des bases de données partagées sont le fondement essentiel de ces trois modes de travail en groupe et de leur intégration. Accessible via des outils de développement d'applications et par les utilisateurs eux-mêmes, une architecture de base de données partagées offre aux groupes de travail la possibilité de définir, de gérer et de maintenir leurs propres processus. De même, la messagerie offre un moyen de transport universel, un mode de communication fondamental pour les personnes et les applications. Cette double architecture est un élément critique pour la souplesse et la facilité de personnalisation de l'environnement. Ce document traite aussi de la nature concrète du travail en groupe : nécessité de gérer les utilisateurs distants et mobiles, hétérogénéité des environnements, des systèmes d'exploitation réseau, serveur et client, et tendance croissante à des utilisations inter-entreprises avec clients et partenaires commerciaux. Il faut surtout noter que l'objectif de ce document n'est pas de clore définitivement le débat sur les applications de groupware. C'est aussi à cause de son dynamisme et de sa nature évolutive qu'aucun consensus ne s'est dégagé sur la définition du groupware et rien ne laisse penser que le rythme cette évolution doive ralentir dans un proche avenir. Toutefois, s'il est probable que les utilisateurs continueront à utiliser le groupware selon des modes inédits et novateurs, les bases architecturales de son infrastructure, principal objet de ce cours ont toutes les chances de rester constantes dans un avenir prévisible. En conclusion, ce papier propose des orientations en matière d'architecture, permettant de bâtir une infrastructure de groupware.

1.1 En résumé Le groupware échappe par bien des aspects à toute définition. Pourtant, cette catégorie de logiciels a su attirer l'attention des professionnels des technologies de l'information, des directions opérationnelles et des utilisateurs, sans parler des éditeurs de logiciels. Nombreuses sont les entreprises pour qui le groupware n'a pas de définition précise, mais elles sont clairement conscientes de deux notions : leur survie et leur réussite dépendent de l'exploitation du savoir de leur personnel et de leurs partenaires commerciaux, celles qui sauront gérer avec efficacité et exploiter leurs atouts intellectuels prendront l'avantage sur leurs concurrentes.

3


Globalement parlant, chaque définition du groupware tend à privilégier une technologie particulière dont les hypothèses de conception sont relativement réductrices. Il n'est guère étonnant, par conséquent, que les fournisseurs de produits centrés sur la communication qui propagent l'information au travers d'une organisation voient dans la messagerie la technologie de base groupware. De même, les fournisseurs de produits de collaboration pour le partage d'informations et la construction d'une compréhension partagée tendent à considérer que les forums électroniques et le partage des bases de données constituent le noyau du groupware. Enfin, ceux dont les produits ont pour cible d'aider les personnes et les Croupes dans la coordination de différentes tâches complexes (par ex. délégation, approbations, etc.), sont portés à considérer comme le sine qua non du groupware les outils de développement d'applications pour l'automatisation des tâches et du workflow En réalité, c'est parce que le groupware est à la croisée de technologies vues Jusqu'à présent comme indépendantes (messagerie, forum, workflow etc.) qu'une telle confusion entoure sa définition et sa portée. Pour autant que cela paraisse évident, si nous partons de l'idée que le groupware doit aider les individus à mieux coopérer d'un point de vue qualitatif, nous voyons que le groupware représente l'intégration de ces technologies. Cet ouvrage s'appuie sur un cadre simple pour le travail en groupe, fondé sur trois catégories :

• Communication - une messagerie électronique dotée de nombreuses fonctions, • Collaboration - favorisant la création d'un espace de travail riche, partagé et virtuel, • Coordination - ajoutant la structure des processus de travail aux deux aspects précédents, pour garantir l'application des procédures d'une entreprise.

Par une analyse approfondie, nous verrons pour quelles raisons chaque modèle technologique, utilisé isolément, n'est pas suffisant. Nous apprendrons que les applications de travail en groupe exigent de riches combinaisons de technologies. En outre, la puissance d'une plate-forme groupware résulte de sa capacité à gérer un mouvement dynamique, entre et à l'intérieur de ces trois modes de travail communication, collaboration et coordination. Le groupware ne se résume donc pas à une simple liste de fonctions et de caractéristiques. C'est en réalité une plate-forme qui se contente, avec beaucoup d'élégance, de refléter cette convergence qui se caractérise par l'intégration de trois technologies de base :

• Un conteneur d'objets qui abrite et gère la mémoire de l'entreprise messages, documents, formulaires, notes de service, rapports. • Un modèle d'accès et de diffusion qui permet aux utilisateurs de localiser et de diffuser rapidement l'information. • Un cadre de développement d'applications qui exploite les services natifs sous-jacents des deux autres technologies.

Une infrastructure de groupware doit naturellement prendre en compte les conditions générales des environnements des groupes de travail, et plus particulièrement :

• Intégration avec les ressources externes. La source des informations du groupe de travail se situe souvent hors de l'environnement du groupware proprement dit (outils de productivité bureautique, bases de données relationnelles, etc.). • Indépendance par rapport aux plate-formes. Même si les applications de groupware prennent souvent naissance dans un service de l'entreprise, elles finissent par être étendues à tous les services. Il faut donc assurer leur indépendance par rapport au matériel et aux réseaux, pour garantir leur généralisation et la pérennité des investissements.

4 Groupware


• Mobilité. Une infrastructure de groupware doit être capable de gérer la dispersion géographique des sites mais aussi : ordinateurs à domicile, et portables en tous genres. • Applications inter-entreprises. Comme les entreprises commencent à vouloir intégrer leurs clients et partenaires commerciaux dans l'automatisation de leurs processus de travail, la capacité à étendre l'application en toute transparence que ce soit immédiatement ou ultérieurement constitue un élément majeur d'une infrastructure de groupware.

Il est naturellement impossible d'écrire une application liée à un «business process» en tenant compte, par avance, de toutes les situations possibles et imaginables. Peu importe le nombre de cas particuliers et d'exceptions prévus, chaque personne découvrira de nouveaux besoins en explorant les profondeurs de l'application et au fur et à mesure de l'apparition de nouvelles situations de travail. Nous en concluons que tout système conçu dans le but de créer, de gérer et d'exploiter le savoir de l'entreprise est, par définition, à l'échelle de toute l'entreprise, et doit donc répondre aux critères suivants :

• Accepter toute la variété des systèmes d'exploitation serveur, réseau et client. • Gérer les utilisateurs mobiles et distants. • Gérer l'interactivité entre les entreprises. en toute transparence.

Tout système de groupware dont l'architecture est «correcte» en ce sens qu'elle gère la convergence des modes de communication, de collaboration et de coordination, est néanmoins voué à l'échec à l'échelle de l'entreprise, s'il ne prend pas aussi en compte la réalité des travailleurs « nomades » et des communications inter-entreprises.

5


2 Définition du groupware Prenez dix personnes, Directeurs de l'information, dirigeants informatiques/télécoms, utilisateurs, fournisseurs et demandez leur de vous donner leur définition du groupware. Il y a fort à parier qu'elles vous feront dix réponses différentes, leur seul terrain d'entente risque d'être qu'elles ne savent pas exactement où commence ni où finit le groupware. Toute tentative d'aller au-delà d'une définition simple : des logiciels qui aident le travail en groupe, insiste généralement sur un aspect spécifique du travail en groupe et sur une application facilitant ce type de travail. Dans leur grande majorité, les utilisateurs n'ont du groupware qu'une expérience fragmentaire : ils ont utilisé une ou plusieurs applications, mais ne savent pas dans quel contexte les replacer. C'est ainsi que les utilisateurs de courrier électronique et d'applications en mode messagerie voient naturellement le groupware sous l'angle de la messagerie électronique. Les utilisateurs du routage de formulaires ont plutôt tendance à penser le groupware en termes d'automatisation du workflow, tandis que les utilisateurs de forums électroniques ou du World Wide Web tendraient plutôt à voir l'essence même du groupware dans l'accès partagé à l'information. Ces divergences s'expliquent par le fait que le groupware puise en fait ses racines dans trois domaines d'application distincts, mais qui se chevauchent de plus en plus : la messagerie électronique, la gestion de l'information et l'automatisation du workflow et des processus. Chacun de ces domaines technologiques a donné naissance aux nombreuses applications actuelles de groupware : courrier électronique, forum électronique et bulletins boards, routage et suivi de formulaires, le plus prolifique étant la messagerie électronique, souvent considérée comme la pierre angulaire du groupware. Mais cessons un instant de nous polariser sur les tâches élémentaires des individus au travail pour prendre du recul et observer le contexte plus général de leur travail. Nous voyons qu'ils passent d'une situation de travail à une autre, changent de mode ou de groupe de travail, jonglent avec des séries de tâches ayant bien peu de rapport entre elles, et dont peu d'entre elles sont réellement achevées, ou disons même dans un état stable, avant la fin de la journée ou de la semaine. Nous voyons des personnes qui décrochent leur téléphone pour demander un éclaircissement rapide, mais souvent cette question reste sans réponse, car l'appel n'a pas abouti. Nous découvrons des groupes de travail qui se font et se défont ; des groupes en création qui en sont à se réunir dans une salle pour définir comment ils vont travailler et des groupes plus «établis» qui se comprennent à demi-mot ou par gestes. Sous un tel éclairage, le groupware ne peut certainement pas se définir comme une technologie unique ou comme une série d'applications. Les besoins des groupes évoluent dans le temps et chaque groupe est différent. Pour être efficace, le système de groupware doit être capable de aérer tous les modes de travail en groupe. En particulier : - La messagerie électronique est un outil efficace de notification, bien adapté aux besoins de communication. C'est une solution si puissante, que les utilisateurs exploitent désormais la mémoire de messages comme une base de données permanente. Ils en ont aussi élargi les fonctionnalités, en organisant les réunions de groupe à partir de listes de diffusion ou pour rédiger et réviser des documents communs.

6 Groupware


- Cependant, les bulletins boards et les forums électroniques (bases de données partagées) offrent une vue commune, bien plus cohérente, de l'interaction des groupes. Ces applications se sont donc répandues dans de nombreuses organisations. Pourtant, les systèmes qui stockent l'essentiel des informations nécessaires aux groupes dans des bases de données commencent à pâtir de la nature fondamentalement passive des technologies classiques des bases de données. Chaque membre d'un groupe doit rechercher l'information et planifier ses actions en fonction des changements apportés à cette information. C'est ainsi qu'est né le besoin d'un usage coordonné de la messagerie, pour la notification, et des bases de données, pour le partage des informations. 11 a donné naissance à une solution unifiée intégrant la messagerie et les bases de données partagées. - Un système de workflow reposant simplement sur le routage de formulaires entre plusieurs personnes laisse également isolés les membres du groupe, en les privant de toute vue d'ensemble du processus. En revanche, un système reposant sur une base de données pour le stockage des éléments importants et de leur état peut renseigner quiconque en a besoin sur le contexte, en utilisant la messagerie surtout à des fins de notification. Le groupware représente ici la convergence de la messagerie, de la gestion de l'information et de l'automatisation du workflow, en répondant à l'évolution des besoins des groupes, en matière de création, de partage et d'exploitation de l'information de l'entreprise. D'un point de vue plus organique, il apparaît nettement que le partage de l'information et du savoir interviennent dans trois fonctions de base : la communication, la collaboration et la coordination. Deux dimensions caractérisent le rôle joué par la technologie dans le travail en groupe : le degré de structuration imposé par la technologie et le rôle passif/actif joué par cette technologie dans le guidage du travail du groupe.

* La première dimension a trait aux différents degrés de structuration requis pour le travail en groupe, allant de situations où l'information est diffusée par un canal ad hoc (un message électronique envoyé à un groupe), à des processus bien plus structurés, dont les étapes sont prédéfinies et de type déterministe, par exemple le routage d'une demande d'achat. * La deuxième dimension a trait à la relation passive/active entre le média technologique et l'individu ou le groupe. Les applications passives sont pilotées par l'utilisateur ou par le groupe de travail, tandis que les applications actives jouent un rôle plus direct, voire directif, en pilotant le flux de travail du groupe. Par exemple, un système de base de données partagées qui permet aux utilisateurs de suivre le fil d'une discussion est de type passif, tandis qu'un système qui surveille un processus et signale à l'utilisateur l'apparition d'un événement, est actif.

Le diagramme ci-après illustre bien la corrélation entre différentes applications de groupware et ces deux dimensions, ainsi que leur relation réciproque. Les systèmes de communication, de collaboration et de coordination revêtent chacun leur propre spécificité. Il faut donc bien comprendre les hypothèses de conception relatives à chacun des domaines pour identifier les critères applicables aux technologies et aux applications. dans chacun d'eux. Collectivement, ces critères sont le fondement de l'évaluation d'une architecture complète de groupware, capables de supporter sans discontinuité, à tout instant et en tout lieu les modes de la communication, de la collaboration et de la coordination.

7


Notre propre définition du groupware se résume à ceci : des outils permettant aux individus de travailler ensemble, par la communication, la collaboration et la coordination. En réalité, ce qui fait toute la puissance d'une plate-forme de groupware, c'est sa capacité à gérer la dynamique entre communication, collaboration et coordination. Les chapitres qui suivent examinent ces domaines en fonction des attentes des groupes et des technologies sous-jacentes.

8 Groupware


3 Communication La communication réside dans la transmission du savoir. Les collègues d'une entreprise communiquent entre eux de bien des manières : certaines formelles comme les réunions, présentations, notes de service, d'autres moins comme les conversations téléphoniques, ou encore les « réunions de couloir ». Lors de ces interactions, le partage des informations et du savoir prend la forme d'une communication à la fois verbale (écrite et parlée) et visuelle (images, dessins, langage corporel). Le rôle du système de communication est celui d'un média électronique passif de transmission de l'information. Des variables telles que le temps, le lieu et le nombre de participants déterminent quel est le système de communication le plus adapté à la situation. Unité de temps, unité de lieu, interaction entre deux personnes, c'est la forme la plus simple de communication. Mais plus l'espace temps et le nombre de participants grandissent, plus la communication devient complexe. Or c'est justement dans les situations de grande complexité que le vrai savoir de l'entreprise se crée, se partage s'exploite. Les individus font de plus en plus confiance au courrier électronique pour leur communication interpersonnelle dans l'entreprise, mais aussi hors de l'entreprise. Et bien que cette technologie ait amélioré l'efficacité et la précision de la communication pour certains, elle a généré de nombreux défis pour d'autres, parmi eux des utilisateurs, et les administrateurs de systèmes et de réseaux.

3.1 Messagerie électronique : une technologie de communication La messagerie électronique est un transporteur en temps différé d'objets électroniques entre personnes, entre personnes et applications, ou entre applications. La messagerie électronique est conçue sur le principe de la transmission asynchrone, d'un lieu à l'autre, de messages pouvant contenir des informations simples ou complexes, destinés à des individus ou à des groupes. Du fait de son principe de diffusion asynchrone, la messagerie permet une forme de partage de l'information indépendant du temps et de l'espace. Nous disons qu'elle fonctionne selon le mode «push»: c'est l'émetteur qui décide de l'envoi vers le destinataire. C'est ce système de transport asynchrone, ou encore «store and forward» qui distingue la messagerie électronique des autres technologies de communication. Les objets, transportés ou «poussés» d'un point à un autre, transitent par un grand nombre de points intermédiaires (de bureau de poste en bureau de poste) jusqu'à leur remise au destinataire final. La connectivité est asynchrone, puisque l'expéditeur et le destinataire n'ont pas besoin d'être dans le même repère de temps. C'est l'avantage réel de ce type de traitement. On reconnaît à la messagerie le mérite d'avoir révolutionné la communication 1 - n (de un à plusieurs). Bien entendu, elle mène rapidement à la communication n - n (de plusieurs à plusieurs). Comme on le voit dans le diagramme ci-après, sur la « toile d'araignée » des chemins point à point, l'utilisation du courrier électronique pour la communication n - n a engendré une croissance exponentielle en volume des messages électroniques. Comme nous le verrons, ce n'est pas une évolution mineure pour la messagerie asynchrone.

3.2 Stockage des messages La mémoire des messages est classiquement l'endroit où sont stockés temporairement les messages avant leur acheminement vers leur destinataire. Mais au fil du temps et avec l'utilisation accrue de la messagerie pour la communication 1 - n et n - n cet endroit est devenu de fait le conteneur de grandes quantités d'informations de l'entreprise. C'est-à-dire que ce qui avait été prévu pour un stockage temporaire «ad-hoc»de messages a fini par servir

9


de mémoire semi-permanente non seulement pour d'éphémères notes de service, mais aussi pour des documents d'un cycle de vie illimité. Comme sa finalité était de fournir un stockage 'temporaire', il a été optimisé en vue de la distribution et de l'extraction des messages, en partant du principe que les documents et les objets acheminés via la messagerie électronique seraient stockés et manipulés ailleurs (par ex. sur le disque dur d'un micro-ordinateur ou sur un serveur de fichiers du réseau local) par expéditeurs et destinataires. Il n'a donc pas été conçu pour le stockage et la gestion permanente de l'information. Il n'en demeure pas moins que les messageries sont devenues la mémoire d'une part croissante de l'information de l'entreprise et les utilisateurs, comme les fournisseurs, ont cherché de nouveaux moyens pour gérer, manipuler et accroître l'automatisation de l'utilisation de cettes informations, par le biais de classeurs, d'agents appliquant des règles et le développement d'applications. Les interfaces de programmation (API) de messagerie ont ainsi permis de programmer l'utilisation de la messagerie, pour transporter des objets entre utilisateur et application, et entre applications. Citons par exemple les applications bureautiques avec fonctions de messagerie intégrées, la gestion du temps et la planification de groupes, le routage de formulaires. Devenue un «hub» de communication virtuelle, la messagerie a engendré un problème majeur de gestion de l'information, qu'elle n'était simplement pas conçue pour traiter. En dépit de l'immense succès rencontré par la messagerie comme vecteur de communi cation, ses utilisateurs commencent désormais à trouver la technologie de moins en moins maniable. Elle induit en effet deux effets qui compliquent la gestion de l'information dans l'entreprise : les utilisateurs ne parviennent plus à gèrer la quantité croissante de messages, et ils ressentent cruellement l'absence de vrais outils de gestion de l'information, pour manipuler le contenu des messages électroniques. Le courrier électronique est victime de son propre succès. Sa facilité d'utilisation et son adoption quasi-universelle ont engendré une explosion du trafic, avec pour corollaires la perte d'information et l'accumulation d'innombrables messages sans réponse. Un temps précieux est consacré à lire et à filtrer des messages sans intérêt. Certains utilisateurs, inondés de messages, ont même pris le parti d'en ignorer tout simplement un grand nombre! Cette situation influe fâcheusement sur la productivité individuelle et sur celle de l'entreprise, provoquant rupture dans la chaîne d'information et moindre réactivité vis à vis du client et, en fin de compte, baisse de rentabilité. Qui plus est, la situation ne peut qu'empirer. La capacité accrue des messageries (par ex. l'envoi de fichiers de 50 Mo à 10 utilisateurs, voire plus) ne fera qu'exacerber ce problème. Le graphique ci-après montre la relation entre volume de messages et productivité. Au début, l'impact sur la productivité est positif, car les personnes reçoivent plus vite l'information dont elles ont besoin. Cependant, plus le volume d'information et la complexité augmentent, plus les utilisateurs se rapprochent d'un seuil d'inversion de productivité. Enfin, ce volume accru d'information influe négativement sur la productivité individuelle, surtout parce que les informations pertinentes sont noyées dans des informations que leur expéditeur a cru nécessaires ou importantes pour le destinataire. Pour y remédier, des agents, macros filtres, classeurs hiérarchiques et autres ont été développés pour aider à gérer toutes ces informations. Parvenus à ce point, nous reperdons le gain de productivité résultant de la plus grande rapidité de transmission des informations, à trier et rechercher l'information pertinente.

10 Groupware


Ce phénomène de surcharge informationnelle et son impact sur la productivité ont été identifiés il y a quelque temps par la communauté de la recherche opérationnelle. Pour mieux le comprendre, il convient de faire la distinction entre les avantages retirés respectivement par les expéditeurs et les destinataires des messages électroniques. Pour les premiers, le courrier électronique accélère leur capacité à diffuser l'information. Les seconds reçoivent les informations plus vite. Mais si le débit de distribution est supérieur à la capacité d'absorption et de gestion, le seuil d'inversion de productivité est atteint. Autrement dit, le courrier électronique résout effectivement le problème de la diffusion pour l'expéditeur, mais finit par enliser le destinataire dans la gestion de ces informations Supposons qu'un responsable envoie un message électronique à une dizaine de personnes, leur demandant de réagir à un projet. Si tous les destinataires envoient une réponse à tous les destinataires d'origine, le nombre de messages ainsi multiplié dépasse vite la capacité d'un seul destinataire à suivre le fil des messages. De plus, il n'existe aucun mécanisme pour aider les participants à identifier à quel message répond quel autre. Plus l'interactiion est importante et plus les participants sont nombreux, plus il est difficile de gérer la dynamique des différentes réponses. Cet exemple illustre la surcharge informationnelle et la perte de contexte de l'information proprement dite. Pour arriver à la racine du problème, il faut examiner de plus près les besoins de la communication n - n et 1 importance que revêt un modèle de gestion de l'information. Il est possible de relier de nombreux problèmes associés à la surcharge des messageries à leur caractéristique fondamentale : la gestion de communications non structurées selon un modèle de «push». C'est dire que le modèle actuel, bien que permettant une communication non structurée efficace, est incapable de gérer effectivement des niveaux d'interaction plus complexes. A l'inverse, les technologies conçues pour gérer les interactions complexes de la collaboration n - n il font appel à un tout autre modèle de diffusion et de gestion de l'information.

3.3 Conclusions Nous avons jusqu'à présent traité isolément le domaine de la communication pour mieux appréhender sa relation avec d'autres aspects de la technologie du groupware. Nous avons montré que la messagerie électronique constituait un support efficace pour la communication entre deux entités et entre une et plusieurs entités. En raison de l'absence de structuration et du volume des informations transmises, il apparaît que la communication entre plusieurs entités devient rapidement impossible à gérer dans cet environnement. Pour définir la technologie la mieux placée pour résoudre ces problèmes, il convient d'établir une distinction entre la distribution et la gestion des informations. En tant que moyen de transport asynchrone. la messagerie est parfaitement adaptée à la distribution d'informations. Mais pour résoudre le problème de la gestion de ces informations. il faut envisager d'autres technologies.

11


4 Collaboration La collaboration repose sur un espace partagé : une salle, un tableau noir, une serviette de restaurant ou un espace partagé « en ligne ». Pierre angulaire de l'acte de collaboration, cet espace est le média nécessaire pour gérer l'ambiguïté inhérente à toute interaction humaine. L'outil de collaboration forme le cadre dans lequel la totalité de la relation dépasse la somme des expertises individuelles des participants. La collaboration peut s'établir entre deux personnes, ou impliquer au contraire le partage d'informations n - n. Des activités telles que la résolution de problèmes, le brainstorming, l'identification et la localisation de données créées par d'autres sont autant de formes de collaboration. A l'instar de la communication, l'une des principales contributions de la technologie au domaine de la collaboration a été l'élimination des contraintes temporelles et spatiales. S'ils sont dans un même espace-temps, les membres d'un groupe se réunissent volontiers. Le téléphone a réduit la barrière des distances, la messagerie vocale celle du temps. En réalité, l'expérience montre que lorsque des groupes intègrent dans leur environnement des technologies favorisant la collaboration, ils sont en mesure de réduire effectivement le nombre des réunions nécessaires à l'échange d'idées et d'informations. Ils peuvent donc optimiser ces quelques réunions en les réservant à des activités où ce type d'échange est le plus fructueux : finalisation de décisions, obtention de consensus, etc. La suite de ce chapitre est consacrée à la collaboration asynchrone (espace-temps différent), en raison de sa complexité, mais aussi du potentiel d'amélioration des processus de travail qu'elle présente aussi dans un même espace-temps. Notre principal objectif sera de définir le rôle joué par la technologie des bases de données partagées et du partage de l'information dans le contexte de collaboration, à commencer par la manière dont la technologie transcende les limitations de la messagerie électronique en matière d'interaction n - n et en poursuivant avec d'autres formes de collaboration.

4.1 Bases de données partagées : une technologie favorisant la collaboration

Dans le chapitre qui précède, nous avons déterminé que la messagerie, utile support de communication universelle, était adaptable à certaines situations de groupe, par ses fonctions de liste de diffusion, mais qu'elle ne répondait généralement pas bien aux besoins d'une interaction n - n Il faut cependant noter que la large diffusion et la nature asynchrone de la messagerie en ont fait aussi, dans la pratique, un support de collaboration. Bien qu'on puisse y voir une extension logique de la messagerie, ce modèle est inadéquat à bien des égards. L'objet premier d'une messagerie est de gérer le suivi de fichiers, sous la forme de messages, de l'expéditeur au destinataire. Les utilisateurs ont donc du mal à suivre les informations par thème. De plus, suivre le contexte des thèmes de discussion dans une série de messages électroniques, pour savoir qui a réagi à quoi et dans quel ordre, est une opération difficile. C'est pour cette raison qu'a été créé à l'intention des utilisateurs, comme prolongement des messageries électroniques, un espace de discussion partagé en ligne. Cet espace introduit généralement une structuration à travers des agents, un contrôle d'accès et un formalisme de la conversation.

12 Groupware


Cousine de la messagerie dans la famille des produits de communication, la technologie des bases de données partagées a évolué dans un tout autre domaine. Ces bases trouvent en fait leur origine dans le système de temps partagé des premiers mainframes. Elles facilitent la collaboration en offrant un espace de travail virtuel commun avec une interface orientée groupe qui permet aux membres de partager des informations et des idées. Contrairement au modèle «push» de la messagerie, la technologie des bases de données partagées est fondée sur un modèle de consultation (« pull ») qui permet à l'utilisateur d'extraire des informations selon ses besoins. Il choisit donc plus librement le moment de se joindre à diverses discussions de groupe, il n'est plus otage d'un calendrier de courrier électronique et il peut à volonté extraire (ou ignorer !) les informations. D'autres aspects distinguent les bases de données partagées des messageries. Elles reçoivent non seulement un ensemble complet de messages, mais elles rassemblent aussi des thèmes de discussion, des documents de référence, des arguments, c'est-à-dire desconnaissances, en un seul lieu, visualisable au travers d'une structure commune, offrant un enreuistrement cohérent des événements. Le tout s'avère indispensable pour la compréhension collective des concepts et des problèmes essentiels. De plus., lorsqu’une vue partagée est fournie, il est important de proposer différentes formes de présentation, chacun ayant besoin de vues privées personnalisées pour sa propre tâche. Ces représentations multiples peuvent répondre au besoin d'un participant qui souhaite visualiser les informations par date, par auteur, par type de document, etc. Mais elles prennent aussi en compte la diversité des centres d'intérêts : par exemple, une présentation par nom de client ou par segment de marché pour le groupe Marketing, par référence ou par nom de produit pour le bureau d'études. Chaque masque serait comme une optique différente, servant à visualiser la tâche à réaliser en collaboration, tout en replaçant les informations dans leurs différents contextes. Pour toutes ces raisons, et comme le travail évolue avec le temps, la disponibilité d'outils de conception légers, pour l'utilisateur final revêt une grande importance. Ces outils rendent les collaborateurs très autonomes dans la personnalisation et la modification de l'information. Si tel n'était pas le cas, le système finirait par être abandonné. La disponibilité d'outils et la facilité de développement ou de personnalisation des applications constituent la clé du succès à long terme de tels systèmes. En premier lieu, sont importantes la possibilité de personnaliser l'interface utilisateur, le niveau de détail des données et des informations visualisables et manipulables, ainsi que la capacité à définir les multiples variables associées à un système. Les produits du commerce, qui livrent une application spécifique (par ex. forums de groupe) sans autoriser l'accès à la plate-forme sous-jacente, sont limités de ce point de vue. Bien que ces systèmes de type «boîte noire» puissent combler un besoin spécifique à court terme, ils n'ont pas la souplesse et la capacité de personnalisation requises pour résoudre une vaste gamme de problèmes liés à la collaboration. Bien plus souples sont les produits qui exposent la plate-forme sous-jacente et proposent des outils et des applications personnalisables. Pour illustrer ce propos, poursuivons l'exemple ci-dessus. Le groupe Marketing doit maintenant analyser les informations client par zone géographique, en plus de l'analyse par segment de marché. Il faut donc ajouter dans la base de données existante un champ pour entrer des informations sur la zone. Seul un outil de travail en collaboration autorisant l'accès à une base de données sous-jacente et permettant la saisie d'informations dans les champs du document peut être modifié pour gérer facilement des demandes de groupe aussi spécifiques (et variables).

13


5 Les applications du travail collaboratif Pour analyser plus avant les conditions requises pour un environnement de collaboration souple et personnalisable, il convient de bien disting uer entre 1 a technologie et les applications qu'elle autorise. Une base de données partagées, souple, au coeur d'un système de groupware, fournit la plate-forme permettant le développement d'une large palette d'applications, allant de simples ba es d discussion aux riches bases de connaissances qui gèrent, par exemple, les systèmes d'assistance technique et les réponses des spécialistes aux questions.

5.1 Forum électronique Les forums électroniques (bases de discussions, forums publics) facilitent la collaboration asynchrone en introduisant une dose de structuration. Celle-ci, bien que passive, favorise le processus de partage, l'organisation et la consultati n des informations via un espace électronique interactif réceptacle des contributions. La résolution de problèmes, par exemple, comprend des tâches d'ordre général comme le «brainstorming» où les idées sont générées, puis structurées et enfin, évaluées. Ces systèmes font appel à la technologie des bases de données partagées car elles offrent la structure nécessaire pour faciliter ces étapes, tout en autorisant une participation sans unité de temps ni de lieu. Avec les forums électroniques, les messages sont dans une base de données partagées, par opposition aux boîtes aux lettres individuelles d'une messagerie. Tous les participants peuvent visualiser les nouveaux messages et y réagir en conséquence. Un animateur peut intervenir et lancer de nouveaux sujets de discussion pour faire passer le groupe à la phase suivante du processus.

5.2 Exploitation des bases de données partagées pour d'autres a plications

Une base structurée de messages peut servir à assurer une compréhension commune dans une discussion. D'autres types de données peuvent aussi être enregistrés sous forme structurée, pour les groupes travaillant dans un domaine d'application précis, par exemple, dans le cas d'un comité de rédaction. A l'appui de l'effort de révision et de commentaire, le document à rédiger peut être enregistré au format d'une base de données, sous la forme d'une série de paragraphes, de chapitres et de sections, visualisables de différentes façons : en linéaire, à l'instar d'un simple document de traitement de texte, en mode plan, en mode révision, ancienne et nouvelle version, etc. Chaque paragraphe peut servir de sujet de discussion, les conversations peuvent être structurées autour des points à controverse du papier, et non autour d'un ensemble arbitraire de thèmes de discussion du type que l'on trouve dans un forum en ligne. Un tel mécanisme de bases partagées rend le contenu de toute application bien plus utile pour un groupe dans sa tâche de développer des documents. Les applications comme les traitements de texte, les tableurs, etc., qui par intégration de fonctions groupware peuvent stocker des informations dans des bases au lieu de fichiers non structurés, deviennent bien plus puissantes. Lorsqu'elles sont entrées dans une base de données partagées, les informations deviennent visualisables en natif par l'application, ou par une interface de groupware plus générique, qui facilite la discussion, le débat et la prise de décision.

14 Groupware


5.3 Kiosques électroniques Les kiosques électroniques - systèmes de la publication électronique pour large diffusion de documents - sont classés dans le groupware car ils facilitent le partage de l'information. Cette information est publiée sur support électronique par un prestataire de service et lue par de nombreux consommateurs. Pour un sujet donné, il s'agit d'une transmission 1 - n de l'information ; connaissances cumulées d'expériences passées contenues dans des documents tels que rapports comparatifs, prévisions et revues, politiques et manuels de procédures, supports de formation, bulletins d'information et périodiques. Afin de mieux comprendre leur rôle dans l'environnement des entreprises, il est utile de comparer et de contraster les kiosques électroniques avec les applications de travail en collaboration. De structure similaire - les deux systèmes font appel au modèle de consultation («pull») - ils permettant aux utilisateurs de parcourir de vastes espaces d'informations publiques ou privées des entreprises. Mais ils diffèrent en ce sens que les applications de travail en collaboration sont interactives, les applications de kiosque électronique sont à sens unique. En réalité, le kiosque électronique est tellement unidirectionnel qu'il serait difficile de dire qu'il s'agit d'une application de travail en collaboration ou de communication. C'est un puissant outil de communication 1 - n doté d'un faible modèle de diffusion. Bien qu'il soit habituellement déployé sous la forme unidirectionnelle, la gestion d'une interaction bidirectionnelle peut améliorer cons idérablement l'utilité de ce type de systèmes. Le kiosque électronique représente généralement une base de données réparties (ou au minimum un système réparti de fichiers) contenant des documents dans leur état achevé. S'il intègre une riche technologie de base de données réparties, il suffit de proposer des fonctions supplémentaires intégrant communication et collaboration pour le métamorphoser en un environnement dynamique. Celui-ci sera alors capable de gérer l'apprentissage et la construction d'une vision commune, et non plus seulement un environnement de recherche et de consultation d'informations à usage personnel. Par exemple, une équipe peut avoir recours à une base de données de discussion pour collaborer sur la portée, la direction et le détail d'une stratégie pour un nouveau produit. Le fruit de cette collaboration sera un document de stratégie, lui-même enregistré dans un système de kiosque électronique. Il sera alors mis à la disposition de tous les publics concernés, internes et externes. Les lecteurs (par exemple, des clients, des analystes financiers et industriels) du document final peuvent émettre leurs propres réactions, recommandations et prévisions. La société peut ainsi inclure un lien entre le document de stratégie enregistré dans le kiosque électronique et une base de discussion, qui sera alimentée par les réactions et les contributions de tous les lecteurs (y compris des auteurs du document d'origine). De plus, les contributeurs peuvent inclure dans leur commentaire des pointeurs vers des documents contenus dans d'autres kiosques électroniques.

5.4 La nature passive des bases de données partagées L'utilisation de bases partagées pour stocker et conserver une information en ligne présente de nombreux avantages par rapport à un modèle reposant sur la messagerie. D'abord, l'information est extraite par le consommateur, en fonction de ses besoins. Il maîtrise mieux la réception et la consommation de l'information, au lieu de maîtriser son expédition, comme c'est le cas pour la messagerie. Cependant, quand cette technologie est utilisée sans aucun support de notification ou de messagerie, elle présente aussi des limites. Etant donné que, par principe, les bases partagées sont utilisées à la demande du consommateur, elles deviennent

15


par nature passives. Il leur manque une fonction pour signaler facilement aux utilisateurs l'ajout ou la modification des informations. Considérez par exemple le cas d'une bibliothèque de références contenant des procédures standards de travail : il est important de notifier les changements au fur et à mesure de la mise à jour de la base. De la même manière que l'avalanche de courrier électronique se traduit par une surcharge informati onnelle, l'explosion résultant de dizaines, de centaines, voire de milliers de bases de données partagées finit par confronter l'utilisateur avec un environnement surpeuplé et paralysant. C'est le même phénomène qui atteint le World Wide Web, avec l'apparition de milliers de nouvelles pages d'accueil chaque mois et en fin de compte d'immenses quantités d'informations stockées dans les bases. Pourtant, des informations importantes, pertinentes, ou très variables, échappent à l'utilisateur qu'elles intéressent.

16 Groupware


6 Le World Wide Web : un outil de travail en collaboration

Le World Wide Web (WWW ou Web) est passé rapidement à l'état de paradigme majeur pour la publication d'informations intra et inter-entreprises et pour d'autres applications de collaboration. Le Web est essentiellement un ensemble de protocoles fonctionnant sur Internet (ainsi que sur des réseaux privés, internes). Ces protocoles servent de base à l'environnement client/serveur qui gère le partage de l'information et, plus récemment, le traitement de transactions et le commerce électronique. Cette évolution rapide a poussé de nombreuses organisations à envisager de fonder sur le Web une gamme beaucoup plus étendue d'applications, nombre d'entre elles entrant dans la catégorie du groupware telle que nous l'avons définie, et plus particulièrement, dans le domaine de la collaboration.

6.1 L'infrastructure du Web Trois technologies essentielles définissent aujourd'hui le World Wide Web, car elles déterminent les transmissions entre un client Web et un serveur Web via un réseau TCP/IP: • HTTP, HyperText Transport Protocol, protocole de transmission entre un client Web et un serveur Web. • HTML, HyperText Markup Langage, langage de description de document utilisé par les documents ou pages du Web. Les traitements de texte classiques font appel à un mode exclusif de représentation des attributs de document tels que polices, espacement, etc. HTML repose au contraire sur des recommandations de formatage, laissant au client le soin de formater effectivement le document. HTML est un sous-ensemble de SGML (Standard Generalized Markup Language), qui fournit les codes définissant les relations hypertexte entre les documents. • XML, Extended Markup Langage, extension à des documents multimédia et plus généraliste que le HTML. • URL, Uniform Resource Locator pointeur vers une ressource d'Internet. Fait office de système global d'adressage des pages stockées sur les serveurs Web. URL contient le nom du serveur Web (ex. WWW.Lotus.Com) et des extensions possibles, définissant une page Web spécifique ou d'autres informations devant être utilisées par le serveur Web. -Nombreux sont ceux qui voient aujourd'hui le Web sous l'angle de progiciels particuliers, mais il ne fait aucun doute que cette situation va rapidement évoluer et que nous verrons dans le Web un ensemble de capacités mises en oeuvre au travers de protocoles spécifiques, s'appuyant sur une vaste gamme de produits. Les logiciels de navigation graphique, ou browsers du Web, tels que nous les connaissons aujourd'hui, seront toujours utilisés, mais nous sommes en droit de penser que les fonctions de navigation du Web seront directement intégrées à d'autres programmes.

17


Un browser sera tout programme activant les protocoles client du Web et un serveur Web sera tout programme activant les protocoles serveur du Web. Nous nous trouverons bientôt dans un environnement où des applications comme les messageries utiliseront les protocoles du Web pour accéder aux serveurs de bases de données, lesquels justement appliqueront les protocoles du Web. Parconséquent, ce qui sera réalisable sur le Web sera à la fois déterminé et limité par les protocoles. Ceux-ci, en particulier HTTP et HTML, ont déjà connu troisx phases de développement et entrent actuellement dans leur quatrième phase par l’intermédiaire de XML. 6.1.1 Première phase : Publication d'informations. La première version de HTML -ne gérait que la publication d'informations via un modèle hypertexte. Un segment de document pointait vers d'autres segments d'autres documents stockés sur d'autres serveurs, les utilisateurs pouvant ainsi parcourir un espace informationnel en mode non linéaire. Chacun pouvait créer des pages Web en HTML et les stocker sur un serveur HTTP et quiconque disposait d'un «browser» pouvait accéder à cette page par HTTP, Les développeurs du Web ont rapidement compris qu'il était impossible de réaliser certaines tâches avec les seuls protocoles du Web. Une solution a donc été développée, appelée Common Gateway Interface., ou CGI. Un URL, outre qu'il référence une page spécifique d'un serveur Web, peut aussi référencer un programme à invoquer sur le serveur Web via l'Interface CGI. Par exemple, un programme CGI peut créer dynamiquement des pages Web. Le Web est entré dans une ère nouvelle, où la publication dynamique pouvait être gérée en plus de la publication électronique classique. Deux exemples simples illustreront cette différence. Dans le premier cas, il s'agit d'un serveur Web stockant des articles de recherche et les mettant électroniquement à la disposition des browsers du monde entier. Lorsque les articles sont mémorisés sur le serveur, ils ne changent plus. Une page index peut être réécrite à chaque ajout d'article sur le serveur, mais le contenu des articles est figé. C'est l'exemple d'un site Web statique. Considérons maintenant une société qui a pour fonction de suivre les sociétés d'un secteur spécifique (par ex. des compagnies aériennes) et qui souhaite rendre ces informations accessibles à des abonnés du Web. Certains informations sont fois définies, peuvent être mémorisées dans des pages Web statiques et, une fois définies, peuvent être mémorisées dans des pages Web standard, accessibles via des liens Web. Mais le prestataire veut peut-être enrichir son service de nouvelles en temps réel. Les informations relatives à une compagnie donnée peuvent inclure des présentations standard de la compagnie. mais aussi des informations de dernière minute. Si un abonné choisit nouvelles dans l'une des pages prédéfinies. il peut invoquer un programme CGI accédant à un service de kiosque, collectant des informations sur cette compagnie aérienne, formatant une page Web qu'il envoie du browser via HTTP. Ce site Web gère l'édition dynamique. Une grande partie de l'interaction à forte valeur ajoutée du Web provient de pages créées dynamiquement via des programmes CGI. Par conséquent, le facteur de déclenchement pour la création de ces applications n'est pas le contenu de HTML et HTTP, mais plutôt le type d'environnement de développement d'applications disponible pour rédiger des programmes CGI capables d'être en interaction avec des sources de données externes. C'est pourquoi nous commençons à voir une nouvelle génération d'outils de développement d'applications pour le Web. Il est parfaitement raisonnable de penser que les riches environnements de

18 Groupware


développement d'applications gérant déjà les applications de collaboration seront aussi capables de gérer les protocoles du Web. 6.1.2 Deuxième phase : Formulaires à champs. Reprenons l'exemple des compagnies aériennes. Les utilisateurs rechercheront sans doute des nouvelles spécifiques (par ex. des nouvelles datant de moins de 24 heures, ou des articles contenant les mots tarifs et international). Nous sommes donc passés de l'édition dynamique aux requêtes interactives. Pour satisfaire ce besoin, nous de,~ons présenter à l'utilisateur une page où peut être entré, par exemple, une chaîne de recherche spécifique. L'extension de HTML par la gestion des formulaires à champs est la caractéristique de la deuxième grande étape de l'évolution du Web. Lorsque les données sont entrées dans un champ, un URL est renvoyé au serveur qui invoque un programme CGI. Celui-ci extrait les données du formulaire, traite l'information et crée dynamiquement une page qu'il renvoie à l'utilisateur. Non seulement ces formulaires permettent au Web de gérer des applications de requêtes interactives, mais ils permettent aussi le développement du commerce électronique et des services de transactions (par ex. systèmes de réservation de transport aérien, services de cotation de titres, catalogues et bons de commande de VPC, systèmes d'assistance clientèle). Pour le fournisseur, les avantages du traitement des transactions sur le Web sont (1) une connectivité mondiale via Internet et (2) support universel de toute machine client équipée d'un browser Web. Si le Web a vu le jour comme système de travail en collaboration destiné au partage des informations via un modèle d'édition, son plus grand intérêt réside aujourd'hui dans les systèmes de transactions et le commerce électronique domaines extérieurs à ce que l'on considère habituellement comme l'informatique de travail en collaboration. Plus nous nous rapprochons d’un modèle d'édition dynamique, plus il devient indispensable de pouvoir Programmer par delà HTML, via CGI, ce qui nous mène à la phase d' évolution suivante du World Wide Web. 6.1.3 Troisième phase : Langages de programmation. La version initiale de HTML spécifiait le mode de formatage d'un document. Vu sous un autre angle, cependant, HTML n'était en fait qu'un langage de programmation simple. Une instruction HTML peut, par exemple, indiquer: lorsqu'un utilisateur clique sur cette zone active, envoyer les coordonnées de la zone active suivante comme requête au serveur Web appropri ë, lequel renvoie un URL. C'est un programme simple. C'est donc l'évolution de HTML qui déterminera la troisième phase de l'évolution du Web. A l'instar des langages de programmation qui ont évolué vers un modèle orienté objet pour s'accommoder des applications modernes, HTML devra évoluer vers un modèle du même type. Les browsers peuvent inclure du code pour interpréter un programme et les pages du Web peuvent inclure des programmes. Lorsque l'on accède à une page du Web et que cette page est transmise au browser qui en fait la demande, le browser interprète le programme et exécute Faction requise (par ex. animer une image). La naissance de langages spécifiques du Web accroît spectaculairement la programmabilité et l'extensibilité de HTML et par conséquent, des browsers. 6.1.4 Quatrième phase : Pages interactives dynamiques. L’aspect Client/Serveur arrive avec l’inclusion d’objets complexes dans les pages HTML avec l’apparition de JAVA et des Servlets. Ces modèles supposent des systèmes permettant la persistance des objets et le multi-threading.

6.2 Contraintes du Web

19


Comme le Web évolue rapidement, ses frontières et ses contraintes sont difficiles à distinguer à ce stade précoce de son cycle de vie. Avec le temps, nous verrons qu'il y a, comme dans toute innovation, des limites à comprendre et à respecter. Nous entrapercevons déjà certains des défis de demain. Ce qui a été au départ le grand attrait du Web et de ses browsers a été la simplicité absolue de la technologie et de son produit. Les browsers étaient compacts, faciles à installer et à utiliser, mais leur complexité augmentera au fur et à mesure qu'ils gagneront en fonctionnalités, par exemple :

• Gestion de plusieurs formats de codage (ex. Adobe Acrobat en plus de HTML). • Inclusion et gestion de plusieurs langages.

g

• Gestion d'un système de fichiers local (ex. fichier de messages local pour un système de courrier écrit pour le Web), utilisé pour la mise en antémémoire de pages Web ou la mémorisation de répliques de données sur les serveurs Web. • Ajout de riches fonctions de sécurité dans les browsers et contrôle d'accès amélioré sur les serveurs.

En clair, il n'y a pas lieu d'être alarmiste au sujet de l'avenir du Web. Au contraire : le Web a exercé et continuera d'exercer un effet profond sur l'industrie des technologies de l'information et sur la société. Cependant, il est indéniable que l'ajout de fonctionnalités entraînera une complexité accrue. L'introduction de la complexité gênera à son tour l'interopérabilité. Aujourd'hui, le Web est véritablement ouvert. Les serveurs et les browsers Web participent de l'interopérabilité, car les protocoles sont simples et uniformément implantés. Maintenant que le Web est passé du stade du projet de recherche, où des concepts comme le profit et les parts de marché sont sans objet, à une industrie en pleine expansion, tirée par le marché, nous voyons apparaître des extensions &propriétaires' de HTML, à tel point que le serveur Web de tel fournisseur fonctionne Mieux avec le browser de 'ce même' fournisseur. Cela risque d'avoir un effet négatif sur les utilisateurs qui devront s'équiper de plusieurs browsers, utilisant peut-être le browser A mieux adapté à son service de cotation de titres et le browser B, optimisé pour fonctionner avec le serveur du grand magasin local. Nous verrons la complexité augmenter encore, jusqu'à ce que les inévitables guerres des standards éclatent et soient gagnées. Nous continuerons a constater un investissement spectaculaire dans le Web et les technologies associées. La technologie du Web a évolué de la collaboration (édition dynamique d'informations) vers le comrnerce électronique. Même si des innovations vont se poursuivre en ce qui concerne les aspects de collaboration du Web, il est plus que probable que le centre de gravité va se déplacer vers le commerce électronique. Le groupware, parti lui aussi d'une base de travail en collaboration, va voir son centre de gravité migrer vers les applications de coordination, qui sont l'objet du chapitre suivant. En examinant leurs voies d'évolution respectives, nous pouvons nous attendre à bien plus de complémentarité que de chevauchement.

6.3 conclusions Au vu des différentes combinaisons de technologies de communication et de collaboration, il apparaît nettement que :

20 Groupware


• La collaboration et la communication ont des exigences distinctes. La messagerie électronique ne permet donc pas à elle seule de faciliter suffisamment le processus de collaboration. La technologie des bases de données utilise un modèle de consultation «pull» pour la diffusion des informations, qui engage les utilisateurs dans le processus de collaboration. • La collaboration exige un système associant les deux modèles de «push» et «pull» et capable d'offrir un cadre solide pour l'exploitation des nombreuses manières qu'ont les utilisateurs de communiquer et collaborer.

Une base de données partagées est essentielle pour le travail courant, pour partager des vues et pour cristalliser les informations en savoir de l'organisation Un moyen d'exploiter l'intégration des modèles de «push» et de «pull» consiste à employer des outils combinant et coordonnant des technologies de messagerie et de bases de données partagées. Ces outils reflètent le besoin pour les groupes de coordonner leur effort de travail - à la fois pour séquencer leurs activités et faciliter la transition entre différents modes de travail. La troisième catégorie de travail en groupe - la coordination - est supportée par ces deux technologies, ainsi que par des outils qui permettent aux groupes de programmer leur utilisation combinée des deux. C'est le thème du prochain chapitre. Coordination Jusqu'à présent, nous avons montré comment les groupes de personnes communiquent et collaborent dans le but de partager l'information et d'exploiter des connaissances qui les aident à s'acquitter plus efficacement de leurs tâches. La caractéristique principale de cette interaction est sa nature non structurée. En effet, ces personnes s'envoient des messages au moment opportun et se réfèrent à des ressources partagées en cas de besoin. Ces activités s'effectuent dynamiquement, au fil des besoins. Pour nous, le terme de collaboration évoque plutôt les sessions de brainstorming, de rédaction collective d'un article de recherche ou d'autres types d'activités créatrices dont nous ne savons même pas où elles vont aboutir. Pourtant, nombre d'activités professionnelles sont beaucoup plus structurées. L'entreprise n'attend pas de ses salariés qu'ils collaborent sur le traitement d'une note de frais ; au contraire, elle définit des règles précises spécifiant le cheminement d'une note de frais dans l'organisation, pour qu'elle soit approuvée, vérifiée et sécurisée. Ces règles impliquent la participation de nombreuses personnes, mais elles stipulent, voire dictent, la coordination requise entre ces personnes pour atteindre un objectif défini. Un processus de travail prédéfini nécessite la coordination des individus en vue de réaliser un ensemble de tâches structurées, dans un ordre précis, dans les délais impartis. C'est dans une grande mesure le domaine des systèmes d'automatisation du workflow - qui insistent sur des processus de travail fortement structurés, offrant des workflows prédéfinis, conditionnels fondés sur un état et des conditions. Si, du point de vue du système, le travail en collaboration est relativement passif (nous créons un espace de travail commun, mais nous ne dictons pas le mode d'utilisation de cet espace), la coordination est très active (nous spécifions les activités à accomplir). Lorsque nous abandonnons la collaboration pour la coordination, afin de résoudre un problème spécifique, nous appliquons des systèmes de workflow, dans lesquels nous définissons des formulaires, nous spécifions des opérations et une logique de routage relatives à ces formulaires, le mode d'accès ou de modification des données externes, des points de déclenchement intervenant lorsque certaines conditions sont réunies, etc. Nous développons

21


des applicaiÏons de workflow. Pour ce faire, il nous faut des outils de développement d'applications. Ici, la coordination renvoie à l'utilisation d'outils de développement pour une classe d'applications connues sous le terme générique de workflow, où un attribut principal suit souvent une ressource. L'environnement de développement d'applications est donc l'outil indispensable pour bâtir des systèmes de coordination. Dans les applications de workflow, J'exploitation de la structure est un élément important, mais il n'en reste pas moins qu'on néglige une partie significative de la coordination qui a trait aux tâches et activités non prédéfinies. Dans la réalité, la plupart des opérations font appel à une combinaison de processus et de tâches fortement structurées, et de processus flous où règles, routage et rôles sont définis dynamiquement au fur et à mesure. C'est pourquoi, pris isolément, sans les composantes de collaboration et de communication assurant une interaction souple, les systèmes de workflow sont souvent inefficaces et considérés comme trop rigides. Prenons l'exemple d'une application de débogage logiciel. Les étapes structurées peuvent être : enregistrement initial de l'incident, soumission à un responsable de projet, affectation à un analyste programmeur, transmission à l'assurance qualité, livraison à un spécialiste de la gestion des configurations, publication dans une bibliothèque de référence publique (exemple : World Wide Web ou bulletin board) en vue du téléchargement par les clients. Ce processus, cependant, inclut probablement plusieurs étapes non structurées, impossibles à prévoir ou à automatiser, comme la référence à une base de suivi d'incidents, permettant d'identifier des incidents similaires, ou les demandes d'informations complémentaires par courrier électronique de la part de diverses parties. La coordination, par conséquent, ne se cantonne pas à automatiser une séquence de tâches structurées, à impliquer des personnes dans un processus en fonction des besoins. Au contraire, en examinant comment s'effectue le travail, nous constatons que les connai ssances essentielles à l'aboutissement d'un processus sont le fruit des relations entre les différents participants, en dehors du contexte strict du processus. Une coordination complète inclut la prise en compte de démarches informelles (courrier électronique, bases de données de discussion, kiosque électronique) au cours desquelles les individus collectent les informations dont ils ont besoin pour s'acquitter de leurs tâches, surtout lorsque ces démarches interviennent dans le contexte d'un processus plus structuré. Dans les précédents chapitres, nous avons vu que chaque modèle de communication et de collaboration, pris individuellement, reposant sur la diffusion ou la consultation d'informations («push/pull»), présentait des lacunes lorsqu'il était appliqué au-delà de son concept d'origine. Une solution intégrée, qui coordonne l'usage de la messagerie pour la notification et des bases de données partagées pour la collaboration, offre une approche plus équilibrée et plus complète pour la prise en compte des processus structurés et non structurés.

22 Groupware


7 Quatre générations de messagerie Les messageries de 4ème génération exploitent la messagerie en coordination avec les bases de données partagées. En remontant le temps, nous constatons que les systèmes de l ère génération n'étaient capables de gérer que de simples messages de texte. Puis les systèmes de 2ème génération ont ajouté la faculté de rattacher des fichiers binaires à de simples messages de texte. Les systèmes de 3ème génération ont su gérer le texte riche (couleurs, polices, tailles de caractère, etc.), l'intégration d'objets dans le corps du message, en plus du rattachement de fichiers binaires. Enfin, les systèmes de 4ème génération représentent un progrès dans le domaine de la messagerie étant capables de gérer des liens hypertexte avec des documents contenus dans des bases de données partagées et des systèmes de fichiers. Au lieu de rattacher un objet, nous insérons dans le message un lienDoc, pointeur électronique vers l'objet situé dans une base de données partagées. Un double-clic sur le lienDoc, et l'objet est automatiquement et immédiatement extrait et présenté à l'utilisateur. La messagerie est améliorée, car l'utilisateur n'est plus obligé d'insérer des objets et des rattachements dans ses messages. Les bases de données partagées y gagnent elles aussi, puisque les utilisateurs disposent désormais d'un moyen de notifier aux autres personnes l'existence d'informations importantes ou pertinentes qui auraient pu rester inaperçues et inutilisées dans une base. C'est ce que nous appelons la solution intégrée de messagerie et de groupware. Imaginons une activité coordonnée de ce type : le directeur de la publicité soumet régulièrement à l'examen d'un groupe de rédacteurs des projets d'annonces imprimées, comprenant du texte et des graphiques. A chaque fois, il diffuse à ce groupe, par le courrier électronique, une annonce, annexée au message électronique sous forme de rattachement de fichier binaire. Les réactions des différents membres du groupe - modifications proprement dites, suggestions, commentaires -génèrent vite un problème de gestion des documents et des versions. Dans le même temps, les allers-retours de ces gros messages augmentent considérablement le volume de la messagerie et, par voie de conséquence, le trafic sur le réseau. A l'inverse, s'il utilise une base de données partagées, le directeur échappe à plusieurs de ces problèmes. La base de données lui permet, ainsi qu'aux réviseurs, de suivre la version la plus récente du document ainsi que les discussions qui ont entraîné de nombreuses modifications. En revanche, cette solution ne dispose pas de la capacité de notification nécessaire lorsque la nouvelle annonce est placée dans la base pour examen. L'utilisation coordonnée de la messagerie et des bases de données partagées dans les messageries de 4ème génération (messagerie et groupware intégrés) résout ce double problème. Lorsque le directeur place une nouvelle annonce dans la base de données partagées, un message électronique est créé, contenant un lien hypertexte ou pointeur vers le document. Le courrier électronique informe les réviseurs de cette nouvelle annonce, mais celle-ci n'est pas physiquement transférée par rattachement au message de courrier. Au contraire, le lienDoc contenu dans le message transfère dynamiquement les réviseurs vers les nouvelles annonces qui demeurent dans une base de données partagées, où elles sont aérées et maintenues de façon centralisée, permettant la gestion des versions et le travail en collaboration. dans un espace partagé.

7.1 Messagerie et groupware intégrés

23


Nous avons déjà noté que les utilisateurs du courrier électronique avaient plutôt tendance à voir le groupware comme une messagerie, tandis que les utilisateurs de forums électroniques et de systèmes d'édition en ligne le considéraient plutôt comme une fonction des bases de données partagées. Enfin les utilisateurs particulièrement intéressés par l'automatisation des processus de travail structurés étaient enclins à le percevoir comme l'automatisation du workflow. Chacune de ces technologies, prise séparément, représente en fait une dimension spécifique du groupware. Les technologies de la messagerie et des bases de données partagées sont devenues chacune le fondement des systèmes d'automatisation du workflow. La messagerie s'est insérée dans l'espace occupé par le workflow en exposant ses API aux fonctions et outils de développement d'applications, pour créer une méthodologie de routage du workflow permettant l'automatisation des processus. De la même manière, les bases de données partagées se sont élargies pour prendre en compte une méthodologie de suivi pour l'automatisation du workflow.

7.2 Modèle de workflow fondé sur la messagerie L’automatisation du workflow est généralement associée au routage automatique de documents, par exemple les notes de frais. Ce routage fait généralement appel à la messagerie sous-jacente pour acheminer les documents à la personne chargée de l'action suivante (par ex. approuver la note de frais). Ce routage peut être prédéfini, ou bien un agent détermine le chemin emprunté, en fonction d'une valeur spécifique (par exemple, le montant) ou d'un rôle (par exemple, le supérieur hiérarchique de l'auteur de la note de frais). Parfois très sophistiqués, ces agents peuvent même invoquer une application externe pour récupérer des données (par exemple, la limite d'autorisation). Le workflow par routage est une puissante méthode qui imite bien le circuit papier : une personne agit sur un document, qui est ensuite envoyé à la personne suivante. Il présente toutefois un inconvénient de taille : une fois en chemin, le document devient inaccessible à toute personne autre que celle qui l'a dans sa boîte aux lettres. Pour mieux comprendre le genre de problème engendré, prenons l'exemple d'un contrat en cours de négociation. Avant d'être signé, le contrat doit être approuvé par plusieurs personnes de la société. Un système de workflow par messagerie achemine le contrat à chaque personne, laquelle est invitée à l'approuver, le rejeter, ou à faire des remarques. Supposons que le client souhaite savoir où en est le contrat, ou y apporter des modifications pendant ce processus d'approbation. Est-il possible de déterminer qui est en possession du contrat à un moment donné du processus ? Si oui, est-il possible de le récupérer ? A quel point peut-on introduire des changements ? Qu'advient-il du processus d'approbation si une modification a été apportée ? On peut toujours anticiper certains de ces problèmes (en réécrivant l'agent ou en ajoutant un nouvel agent tenant compte par exemple du fait qu'une personne est en congé), mais bâtir une application stratégique sur des corrections sommaires de ce type est une solution bien peu confortable pour la société, sans compter qu'il est impossible de prévoir toutes les conditions et exceptions.

7.3 Modèle de workflow fondé sur une base de données partagées Fondé sur une base de données partagées, le second modèle permet aux utilisateurs de consulter une base de suivi pour vérifier l'état de documents spécifiques.

24 Groupware


Ce modèle présente un triple avantage. D'abord, résidant sur le serveur, la base de données est soumise aux processus du serveur (déclenchements, agents ou macros des SGBDR) capables d'initier une action sans activité spécifique de la part de l'utilisateur. Dans bien des cas, cette action peut résulter directement de l'absence d'activité de l'utilisateur (un vendeur n'a pas contacté un client depuis 3 jours, un état mensuel n'a pas été soumis, un contrat à approuver attend depuis plus de 24 heures, etc.) ou d'une condition externe (le stock atteint le seuil de réapprovisionnement, une date limite approche). Deuxièmement, le document ou l'enregistrement en question reste accessible aux autres personnes pendant tout le déroulement du processus. Dans l'exemple du contrat, l'original du contrat pourrait être modifié dans la base de données, et, selon les changements, le workflow se poursuivrait ou serait interrompu et lancé de nouveau. Le troisième avantage réside dans le fait que ce modèle facilite grandement la gestion et la macro-gestion du workflow Le serveur peut contrôler des instances spécifiques du processus tout en conservant des statistiques consolidées du processus global, ces dernières assurant une gestion et une planification améliorées du workflow. La principale contrainte du modèle réside dans l'absence de notification sur événement de la part du système. C'est donc à l'utilisateur que revient l'obligation de vérifier la base de données.

7.4 Un modèle intégré Les contraintes associées aux deux modèles de workflow ne nous sont pas inconnues, car elles sont le reflet des technologies sous-jacentes. La messagerie est très efficace lorsqu'il s'agit d'envoyer un document, mais n'offre aucun moyen de gérer ce document une fois qu'il est envoyé. Les bases de données partagées sont efficaces pour la gestion des documents et la présentation d'un tableau d'ensemble, mais leur faiblesse réside dans leur incapacité à avertir les utilisateurs d'un changement d'état ou d'information. Nous avons déjà vu les avantages associés à un système totalement intégré de messagerie et base de donn'es partagées, dans la messagerie de 4ème génération. En généralisant ce modèle, il devient évident que les applications de workflow reposant sur une plate-forme commune qui gère en natif les deux modèles - un sous-système de messagerie doté de capacités de routage conditionnel et une base de données partagées pour mémoriser, extraire, visualiser et gérer les processus de travail - offrent à la fois la robustesse et la flexibilité requises pour une automatisation effective de ces mêmes processus. A titre d'exemple, voyons comment le système de routage et de suivi des contrats présenté plus haut pourrait être appliqué par un modèle intégré. Ce contrat est créé et mémorisé dans une base de données partagées. Lorsqu'il est enregistré, un message de courrier est envoyé au premier approbateur. Il ne contient pas le contrat, ni n'indique son emplacement à l'approbateur. Il contient uniquement un lien hypertexte qui, lorsqu'il est activé, lance le contrat en vue de son utilisation par J'approbateur, tout en le conservant dans la base de données. D'autres approbations et routages peuvent être effectués, mais la version la plus récente du contrat proprement dit reste disponible en permanence dans la base. Toute requête relative à son état peut être satisfaite par quiconque a accès à la base.

7.5 Modèle élargi de transaction

25


Comme nous l'avons vu, les systèmes de workflow font appel à deux méthodes essentielles, l'une fondée sur un modèle de messagerie, l'autre sur un modèle de base de données partagées. Les plus réussis seront les systèmes de workflow gérant les deux modèles, tout en supportant des fonctions de collaboration moins structurée. Il faut toutefois reconnaître que ces systèmes de workflow sont rarement isolés. Le plus souvent, les processus sont des composantes front-office liées à des systèmes spécifiques de back-office automatisés depuis longtemps. Par conséquent, le lien existant entre la sortie du système de workflow et l'entrée du système classique de traitement des transactions est critique. La procédure d'achat en est un parfait exemple. Tout système d'achat débute par une demande d'achat approuvée et donne lieu à un bon de commande officiel. Ces systèmes sont normalement très bien automatisés et la majeure partie des réductions de coût découlant de J'automatisation a déjà été réalisée. L'entrée de ce système est une demande d'achat approuvée. Celle-ci est en fait le fruit d'un processus de travail entamé lorsqu'une personne décide qu'elle a besoin d'acheter quelque chose. Elle émet donc une demande d'achat, laquelle suit son chemin dans le système, jusqu'à son approbation ou son rejet. Une fois approuvée, la transaction au sens classique du terme est initiée. Dans la réalité, cependant, la transaction a été initiée au moment de l'émission de la demande d'achat. Presque tous les systèmes de back-office intègrent une composante significative de front-office de workflow. Cette vision plus large et plus professionnelle des transactions, nous J'appelons le modèle élargi de transaction. En créant un lien étroit entre le processus de front-office et le processus existant de back-office, nous pouvons réaliser des gains économiques significatifs. Pour créer ce lien, nous devons utiliser des o'Is nous permettant d'interagir avec une grande maîtrise avec les systèmes de transactions existants. De nombreux systèmes de traitement des transactions gèrent cette forme d'interface de programmation. Si nous considérons le workflow comme élément d'une transaction élargie, il devient tout à fait évident que la clé du développement de riches applications de workflow/coordination réside dans un environnement de développement faisant partie intégrante du système de workflow.

7.6 Cadre de développement d'applications Un riche environnement de développement destiné à créer des applications de coordination doit englober un grand nombre de composantes essentielles :

• un outil complet pour la définition et la saisie des masques. Les masques contiendront du texte, des images, du son, des champs, des boutons, des zones de liste, etc, Ils peuvent se subdiviser en sous-masques : fenêtres ou boîtes de dialogue avec les zones de liste familières, etc. De puissantes fonctions d'édition sont requises pour les champs, cette édition pouvant nécessiter l'interfaçage avec des bases de données externes pour valider les entrées effectuées par l'utilisateur. • une programmation, sous la forme d'un langage script, de macroprogrammation ou de programmation complète. Un jeu complet d'API avec la technologie sous-jacente est indispensable. Les développeurs doivent pouvoir fournir des instructions (par ex. au moyen de scripts) pour des événements tels que l'ouverture d'un masque, là modification d'un champ ou l'ajout d'un nouveau document dans la base.

26 Groupware


• une fonction agent, pour décider des actions (par ex. l'exécution d'un script) faisant suite à un événement spécifié. • un environnement de développement avec aide à la mise au point. • des vues personnalisables par l'utilisateur, pour gérer l'affichage personnalisé d'informations, en fonction des besoins de la tâche, de l'individu et du groupe.

Bien utilisés pour le développement, ces outils peuvent produire des applications très robustes offrant à la fois une interface utilisateur naturelle et le lien nécessaire avec les applications de l'entreprise.

7.7 conclusions La plupart des processus de travail sont flous et les agents, routes et rôles sont en fait déterminés par le travail à réaliser. C'est dans ce contexte flou que l'exploitation des connaissances est la plus critique et que les professionnels sont responsables de la gestion de leurs tâches. Notre exposé des activités structurées et non structurées dont est fait tout processus de travail nous mène aux conclusions suivantes :

• Dans la réalité, une grande partie du travail implique un mouvement dynamique entre des tâches structurées, non structurées, 'ad hoc' et prédéfinies, nécessitant un modèle intégré de diffusion/consultation («push/pull») pour aider les utilisateurs dans la transition d'un type de tâche à l'autre, dans le déroulement normal d'un processus. • Les activités de groupe, structurées et prédéfinies, peuvent être gérées par des applications programmées de workflow, répondant à deux types : le routage, fondé sur la technologie de la messagerie et le suivi, fondé sur la technologie des bases de données partagées. L'intégration de ces deux approches de l'automatisation du workflow est possible si l'environnement de développement sait combiner les deux modes. • L'environnement de développement d'applications est bien une composante essentielle de l'architecture d'un système de groupware. C'est ce qui sera traité en détail dans le chapitre Architecture du groupware.

27


8 Architecture du groupware Nous avons jusqu'à présent établi la nécessité d'une infrastructure de groupware capable non seulement de gérer des applications dépendant chacune de la communication, de la collaboration ou de la coordination, mais aussi d'exploiter la synergie engendrée par l'intégration de ces trois éléments. A partir de ces points de référence, nous pouvons déterminer les besoins les plus importants en matière d'infrastructure.

• Un modèle d'information fondé sur une base objets répartie et partagée hébergeant et aérant les données, quelle que soit leur source initiale. • Un modèle de diffusion et d'accès fondé sur la messagerie et la réplication de bases pour assurer l'acheminement des données entre différents lieux et différentes personnes de l'organisation. • Un environnement de développement d'applications exploitant les services natifs sous-jacents de la base objets et du modèle de diffusion/accès en vue du développement sur mesure d'applications de groupware.

Si ce sont là les composantes essentielles d'une architecture intégrée de groupware, l'intégration avec les sources de données externes, la sécurité et les services d'annuaire ont une importance également critique.

8.1 Modèle d'information : la base objets du groupware Le coeur de l'infrastructure du groupware est constitué par la base objets. Pour devenir le véritable dépositaire des informations de J'entreprise, elle est définie par sa capacité à autoriser un accès partagé entre les utilisateurs et les applications, ainsi que nous J'avons déjà indiqué. Plus spécifiquement, c'est le fichier de messages de la communication, l'espace commun virtuel du travail en collaboration et la base de données partagées de la coordination. Intérieurement, la base objets doit être cohérente avec ces trois types d'applications. Autrement dit, rien ne justifie que la structure interne du fichier de messages d'une boîte aux lettres utilisateur soit d'architecture différente de celle d'une base forum ou d'une application de workflow Le 'look' de l'interface utilisateur peut être radicalement différent, mais en profondeur, l'organisation des données en champs, types de données riches, attachements et objets peut, et doit rester cohérente. Ce modèle offre les avantages suivants :

• méthode cohérente de traitement de l'information. à tous les stades de la commun] cation, de la collaboration et de la coordination - à la fois pour les utilisateurs et pour les développeurs d'applications. • séparation véritable entre données et applications. • un seul ensemble cohérent d'informations pour de multiples usages suppression de la redondance des données et des problèmes y afférents.

La base objets du groupware est une base de données répartie et partagée, Au niveau le plus fin, elle contient des objets. Un environnement de groupware réparti se compose d'un réseau arbitraire de serveurs. Dans chaque serveur. il y a un ensemble de bases. Dans chaque base, un ensemble de documents. Dans chaque document, un ensemble de champs. Le document est normalement une forme de présentation des données à l'utilisateur. C'est l'unité de

28 Groupware


mémorisation. La capacité de gérer les informations à ce niveau de détail autorise un traitement des informations bien plus puissant qu'avec un fichier de messages classique. Pour former un système durable de gestion de l'information, la base objets doit gérer les éléments suivants :

• Objets riches. La variété des types d'objets gérés par une base objets définit ou limite la diversité des applications qu'elle peut gérer. La richesse des objets contenus dans les documents est in objectif majeur nombres, texte, texte riche, graphiques, images, voix, vidéo, liens avec d'autres documents, applications intégrées. • Hiérarchie des documents. La base objets nécessite une fonction permettant de conserver le fil des documents, en préservant la relation parent-enfant entre les documents et leurs réponses. Cet élément prédomine dans les bases forum de groupe et de discussion. • Gestion des versions. La gestion des versions au fur et à mesure de l'évolution des documents constitue un élément critique du partage de documents, lorsque plusieurs auteurs interviennent. • Liens hypertexte. La gestion des liens entre documents, dans les bases et avec d'autres bases, offre le meilleur niveau de flexibilité pour référencer les informations mémorisées. Ces liens doivent faire partie intégrante du document., pour assurer leur maintenance et leur gestion dans un environnement réparti. • Cohérence. Toutes les applications d'une base objets sous-jacente doivent reposer sur un ensemble commun de principes d'architecture. Cette cohérence autorise la mise en oeuvre de fonctions importantes du système tout entier. L'indexation plein texte et les fonctions d'extraction intégrées au système de groupware peuvent agir uniformément sur tous les ty es de documents mémorisés, qu'il s'agisse d'une application de courrier électronique ou d'un groupe d'assistance. Les utilisateurs ont ainsi une expérience cohérente des utilisateurs en matière de données et d'applications, indépendamment de leur forme ou de leur emplacement…

8.2 Technologies de distribution 8.2.1 Routage asynchrone Le routage asynchrone est la clé de la messagerie et du modèle «push» de la communication. Il repose sur un transport asynchrone, en différé, pour acheminer les informations de l'expéditeur au destinataire. SMTP/MIME et X.400 ont acquis le rang de standards de l'industrie pour les transporteurs de messagerie. Il est important que ces standards soient supportés, car ils jouent un rôle majeur dans l'intero érabilité des messageries, entre environnements p hétérogènes, intra ou inter-entrepri ses. Lorsque les messages atteignent leur destination finale (le fichier de messages ou la base objets), un utilisateur peut les répliquer du serveur vers son client, pour les exploiter en mode local déconnecté. Prenant la forme de documents, les messages de courrier sont traités comme n'importe quel autre document de la base objets, héritant de tous les services de. cette base (voir Réplication ci-après). Pour le routage entre serveurs, cependant, les messages de courrier

29


sont distribués différemment des autres documents. par des mécanismes de transmission asynchrone. 8.2.2 Réplication La base objets du groupware est une base de données répartie et partagée. Tout en conservant les avantages du modèle informatique réparti, la technologie doit proposer une vue cohérente et logique d'informations physiquement réparties. La réplication des bases permet de synchroniser les changements apportés à plusieurs copies d'une même base, sur des sites géographiquement distants. Par exemple, le site de San Francisco peut répliquer une base située à Paris. Les utilisateurs de San Francisco accèdent ainsi aux informations sur leur serveur local, au lieu de se connecter au serveur de Paris. La réplication synchronise automatiquement les modifications apportées sur les deux sites, afin que les groupes de travail de San Francisco et de Paris disposent d'une vue logique cohérente de la base. Le processus de réplication examine les documents ajoutés, modifiés ou supprimés de chaque serveur et actualise les deux bases, pour les rendre identiques. Si le processus de réplication semble simple au premier abord, il faut toutefois en examiner de près les mécanismes au moment de choisir une technologie. Les mises en oeuvre varient considérablement, ce qui n'est pas sans effet sur les topologies de réseau requises pour un environnement réparti. Voici un examen plus approfondi des besoins de la réplication

• Réplication bidirectionnelle. Après la synchronisation de deux répliques d'une base, les membres du groupe de travail des différents réseaux et serveurs commencent à procéder à des changements, des suppressions ou des ajouts sur ces répliques. C'est dire qu'à la fin du processus de réplication, les deux répliques recommencent à se désynchroniser. Par conséquent, lors de la réplication suivante, le serveur de San Francisco doit pouvoir répliquer tous les changements, ajouts et suppressions vers le serveur de Paris, tout en répliquant tous les changements, ajouts et suppressions du serveur de Paris. Le réplicateur doit signaler tout conflit.

• Efficacité. Comme les entreprises sont souvent équipées de réseaux très différents, le processus de réplication doit être très adaptable et optimisé pour réduire autant que possible le volume du trafic. La granularité de la réplication détermine plus que tout le niveau d'utilisation du réseau. Par exemple, le serveur de Paris n'est pas obligé de recopier l'intégralité de la base de San Francisco à chaque modification d'un champ ou d'un document. Seuls seront répliqués les champs modifiés sur l'un ou l'autre serveur.

• Réplication Client. Les utilisateurs mobiles ou «nomades» d'un groupe de travail doivent disposer du même niveau d'accès aux bases sur serveur que les utilisateurs sur le réseau. Le mode d'accès et d'utilisation des informations doit être cohérent, que l'utilisateur soit sur le réseau ou non. Par conséquent, la réplication ne doit pas se limiter à la connectivité entre serveurs, elle doit aussi assurer la connectivité client-serveur. La réplication client/serveur permet à l'utilisateur mobile de maintenir une réplique locale d'une base (ou de plusieurs bases sur plusieurs serveurs différents) et de travailler sur cette réplique en différé. Lorsqu'il se reconnecte au serveur, la réplication lui sert à synchroniser les changements apportés en différé. Ensuite. la réplication entre serveurs prend la relève et diffuse les changements dans toute l'entreprise. Cette capacité de choisir des documents et des bases à emporter en -voyage est une extension naturelle de la préparation de notre attaché-case. Tout le contenu d'une base pouvant être répliqué, la réplication client permet aux utilisateurs de maintenir un niveau cohérent de communication, de

30 Groupware


collaboration et de coordination à tout moment, en tout lieu. Les utilisateurs «nomades» peuvent emporter en même temps le fichier des messages (courrier électronique), les bases de discussion, les informations de référence et toute application de coordination ou de workflow

• Programmabilité. La réplication doit laisser une grande liberté aux administrateurs et aux utilisateurs, en leur permettant de choisir une réplique sélective des documents, en fonction de critères pertinents : par exemple, les documents qui ont changé depuis une certaine date, les documents par auteur, par taille ou par nom de client. Etant donné les contraintes de temps et d'argent (accès limité à des lignes téléphoniques coûteuses, communications sans fil ou espace disque limité) les utilisateurs mobiles ont encore plus besoin de ce type de programmabilité.

• Diffusion des applications. L'un des défis découlant d'un environnement multi-plates-formes client/serveur réparti, a trait à l'installation et à l'évolution des applications, problème exacerbé dans un environnement de groupware où les besoins des groupes changent constamment. C'est pourquoi J'environnement de développement doit exploiter les capacités de diffusion/répli cation des données de la base à objets. C'est-à-dire que la réplication doit servir à diffuser les objets applicatifs et les modifications d'applications aussi facilement que les données. Lorsqu'un utilisateur accède à la base objets, c'est la version la plus récente de J'application qui doit être lancée. L'infrastructure du groupware fait appel à la réplication pour diffuser et dé loyer automatiquement les données et les mises à jour p y des applications lors de la connexion client/serveur. Ainsi, les développeurs d'applications et les administrateurs de systèmes échapperont-ils à la lourde tâche que représente 1 ' installation manuelle d'applications nouvelles ou modifiées sur des clients et des serveurs répartis dans toute l'entreprise.

• Transfert de point à point La fiabilité de la synchronisation des bases dépend d'un moyen interactif de protocole de transmission (handshaking) entre les systèmes. Par définition, le modèle requis doit être synchrone. Le protocole RPC (Remote Procedure Cal]) offre pour la réplication un transport fiable de point à point, par des connexions directes avec le point d'extrémité.

Voilà qu contraste avec le modèle asynchrone utilisé dans le transport de messagerie, qui achemine les messages par «bonds» successifs. Sur ce modèle, les changements apportés à une base pourraient être diffusés aux autres bases. Au premier abord, cette solution peut sembler astucieuse, car elle exploite une infrastructure de messagerie existante. En pratique, toutefois, ce type de réplication s'avère bien plus complexe et difficile à gérer, l'un des problèmes les plus délicats étant que la garantie de distribution des données-message est beaucoup moins déterministe que dans un environnement de point à point. La messagerie asynchrone implique, par exemple, une périodicité inconnue. Autrement dit, on ne sait pas forcément avec précision combien de temps il faudra à un message de courrier électronique pour parcourir la totalité de son trajet. Cela est d'autant plus vrai dans les grands réseaux publics ou privés où le routage d'un message électronique est déterminé de manière dynamique, au fur et à mesure de son cheminement (qui peut donc être différent à chaque fois). Il est donc difficile de savoir quand, et même si, les bases objets sont effectivement à j Our.

8.3 Environnement de développement d'applications L'une des caractéristiques majeures d'une plate-forme de groupware réside dans sa capacité à gérer le développement et le déploiement rapides d'applications. La plate-forme doit être

31


capable de gérer tout le développement d'applications, de l'utilisateur final sans aucune expérience de la programmation, au développeur professionnel, sans oublier l'utilisateur déjà expérimenté. Il est évident que chaque catégorie a ses propres exigences, l'utilisateur final recherchant une grande facilité d'utilisation, le développeur professionnel ayant quant à lui besoin d'un environnement de développement robuste. Cette robustesse doit effectivement le libérer de la plupart des considérations liées au développement des applications.

Plates-formes. L'infrastructure de groupware faisant office de tampon entre les applications et leurs environnements sous-jacents d'exploitation matérielle/logicielle, les applications peuvent être développées sans se soucier de leu r système d'exploitation final (client, réseau ou serveur). Tous les attributs spécifiques du système, tels que les caractéristiques particulières à une interface graphique, sont geres sans programmation ni modification complémentaire. Diffusion des applications. La logique applicative étant traitée comme n'importe quel objet de la base à objets répartis, les développeurs peuvent exploiter les capacités de diffusion de cette base pour leurs applications. Ils n'ont plus à se préoccuper de la diffusion et de l'installation des applications et de leurs mises à jour. Les applications s'auto-diffusent et se déploient facilement sur le site, où qu'iI se trouve. Support des utilisateurs mobiles. La capacité de l'infrastructure de groupware à gérer les utilisateurs mobiles n'oblige plus les développeurs à créer des version mobiles personnalisées de leurs applications. Chaque application a le même comportement, qu'elle soit utilisée en mode connecté ou déconnecté.

8.4 Langages et outils de programmation Nous venons d'indiquer que, dans une infrastructure intégrée de messagerie et de groupware, la logique applicative se trouvait dans la base à objets. Outre qu'elle libère le développeur des questions de déploiement, elle offre une plate-forme moderne pour un prototypage rapide des applications. Lorsque la logique est dans la base, aucune compilation n'est requise. L'application peut être diffusée à un groupe d'utilisateurs à des fins de test et de validation. Toute modification demandée par les utilisateurs est opérée de la même manière et redéployée, sans un long processus de redéveloppement et de redéploiement.. Deux ensembles de critères s'imposent au langage de programmation intégré à cet environnement. D'abord, le langage de programmation doit satisfaire les exigences de base de tout environnement de développement, qui le distinguent du développement par modèles et langages de macros : Entièrement structuré. Pour créer des applications de groupware avancées, les développeurs ont besoin de fonctions logiques et d'ordres d'exécution complexes, ainsi que de structures de programmation telles que boucles et branchements. Environnement de développement professionnel. Contrairement à l'interface à li-ne de commande dépouillée qui distingue la plupart des langages macro, un langage de programmation de groupware robuste, comme tout autre langage de programmation, nécessite un environnement de développement moderne, interactif et doté de toutes les fonctions

32 Groupware


nécessaires, y compris un éditeur évolué, un browser de bibliothèque de classes et un programme de mise au point interactif, car le langage de programmation est un outil destiné aux développeurs professionnels et aux utilisateurs justifiant d'une expérience de programmation réelle. Niveau élevé d'abstraction. Les systèmes client/serveur modernes - avec leurs interfaces graphiques déclenchées sur événement - exigent un niveau élevé de compétence de la part des développeurs. Le langage doit leur permettre de créer ce type d'interface. sans passer par une programmation détaillée. Gestion d'interfaces utilisateur modernes. Le langage de programmation doit faciliter le développement d'interfaces utilisateur graphiques, notamment la création, l'affichage et la modification de masques, la création de fenêtres en incrustation (par ex. boîtes de dialogue), et aérer des outils d'interface graphique standard tels que boutons, zones de listes, etc. Il doit gérer un puissant traitement des événements, permettant au développeur de spécifier l'action à exécuter lorsque l'utilisateur clique avec la souris ou entre des données dans un champ, par exemple. Le deuxième groupe de critères a trait au fait qu'un langage bien intégré doit tirer parti de tous les services système des plates-formes de groupware. Il est alors possible de distinguer entre des outils de développement qui supportent le développement d'applications de groupware, mais n'exploitent pas nécessairement les services spécifiques d'une infrastructure de groupware. • Gestion des plates-formes Client et Serveur. La plupart des applications de groupware incluent des fonctionnalités sur le serveur et sur le client. Les applications créées par un langage de programmation ne doivent pas, par conséquent, se limiter à des scripts client ou serveur, à l'inverse des langages de script des bases de données classiques, qui opèrent uniquement sur le serveur, sous la forme de processus enregistrés. De même, les langages de programmation bureautique ne sont exécutés naturellement que depuis les plates-formes bureautiques. Un langage de programmation de groupware unique devrait transcender les limites du réseau, de part et d'autre, afin de tirer pleinement parti de l'architecture client/serveur. • Accès natif aux services du système. Les développeurs ont besoin d'un accès complet aux capacités de la base objets et de l'infrastructure de messagerie. Des fonctions conu-ne la réplication, la sécurité et la messagerie doivent être accessibles au développeur en natif, via le langage de progranunation. • Support multi-plates-formes. Les applications de groupware client/serveur supportent des entreprises entières et transcendent parfois leurs limites pour inclure les clients, les fournisseurs et les partenaires commerciaux. Les programmes écrits avec un langage de programmation de groupware, par conséquent, doivent aussi être exécutables sur la panoplie complète des plates-formes client et serveur. De plus, ils doivent s'exécuter sans modification ni recompilation imposée par des conditions particulières à chaque plate-form e. Interopérabilité. Pour créer ou modifier une application, les développeurs professionnels auront sans doute recours à plusieurs outils de programmation. C'est dire qu'ils devront donc utiliser aussi des modèles, des boutons pré-programmés et le langage macro d'un environnement de groupware. Ce langage de programmation doit donc être en totale

33


interopérabilité avec ces autres objets de développement. De plus, le langage doit permettre aux développeurs d'appeler librement des API tierces pour produire une intégration système complexe. Un langage de programmation intégré satisfaisant ces critères est une alternative intéressante aux modèles, langages macro et outils et langages, tiers et autonomes, pour la création d'applications de groupware client/serveur à forte valeur ajoutée.

8.5 Développement par l'utilisateur final Le plus grand défi posé à une infrastructure de groupware résulte de la nécessité de concilier deux principes diamétralement opposés : créer des applications utilisables par des groupes, tout en prenant en compte le besoin ou la volonté de certains utilisateurs de visualiser des composantes de cette application partagée, d'une façon personnalisée. En décrivant les caractéristiques essentielles du cadre de développement d'applications de groupware, nous avons mentionné la nécessité d'accéder en natif aux services de la base à objets et des services de diffusion. De même, les utilisateurs eux-mêmes ont besoin d'accéder en natif aux données enreaistrées dans le modèle objet pour les manipuler à des fins spécifiques. Les exemples ci-après illustrent des extensions personnalisées d'applications existantes : Vues personnalisées. Aucun format optimal unique n'existe pour la présentation des informations. Chaque membre du groupe a ses propres exigences, certains préférant le tri des documents par date, par nom, ou par titre. De plus, la quantité d'informations affichée est aussi affaire de préférence. C'est pourquoi les utilisateurs modifieront l'application en créant des vues privées. Catégorisation La plupart des utilisateurs classent les informations par catégorie : nom d'un projet, référence client, thème (par ex. informations 01 sur la concurrence). En réalité, certains éléments peuvent appartenir à plusieurs catégories. Le point important, ici, est que l'utilisateur définisse ces catégories, car c'est lui qui donne un sens à leurs noms. Tous les documents liés à un projet de débogage seront classés par une personne dans la catégorie débogage, par une autre dans la catégorie Prioritaire et par une autre sous le nom de code du projet. Agents. Chaque personne a sa propre perception de l' importance, de la pertinence ou de l'urgence C'est une chose de recevoir des informations d'autres personnes qui décident ce qui est urgent ou important. C'est une toute autre chose de devoir trier un montage d'informations, en décidant soi-même de ce qui est, ou n'est pas, important. Par des agents, l'utilisateur peut automatiser la recherche d'information. C'est alors le système de groupware qui cherche, trouve et récupère les informations, à partir de critères définis par l'utilisateur. Elargissement. Les petits groupes deviennent souvent grands, et les applications conçues à leur intention doivent absorber plus d'utilisateurs. Le service Marketing inclut dans un processus de travail des membres du service Ventes et du service Développement produit. Il faut donc permettre à ces nouveaux membres d'accéder à l'application et aux données qu'elle contient. Au lieu de solliciter le concepteur, les utilisateurs qualifiés peuvent modifier la liste d'accès, afin d'élargir la portée de l'application.

34 Groupware


8.6 Intégration avec des sources de données externes La plupart des informations enregistrées dans une application de groupware y sont en fait créées, étant entrées directement dans un document. Pourtant, dans leur ensemble, les processus de travail font appel à des données existant ailleurs. Une infrastructure de groupware doit pouvoir, en toute transparence, importer, partager et exploiter les données structurées stockées dans les bases de données relationnelles, ainsi que les données semi-structurées provenant de sources telles que les outils bureautiques (par ex. traitements de texte et tableurs), les systèmes de gestion documentaire et les réseaux publics d'information. Données relationnelles. Les données semi-structurées donnent souvent le illustrant la signification et la pertinence des données structurées. Les statistiques d'inventaire et de traitement des commandes sont plus parlantes si elles sont accompagnées de détails tels que description des cycles de vie des produits, techniques de fabrication, changement complet d'environnement concurrentiel, réaction des clients. Il est évident que l'intégration de données structurées et non structurées est indispensable aux applications et infrastructures de groupware. Par définition, la base à objets du groupware ne peut pas supplanter le SGBDR, car celui-ci nécessite certaines caractéristiques (verrouillage puissant, transactions, exécution/restauration). A l'inverse, la base à objets du groupware nécessite le support d'un modèle réparti à connexion occasionnelle. Ces deux technologies se complètent. Serveurs image/vidéo. De même, les mémoires d'images et les serveurs vidéo ont certaines exigences spécifiques une mémoire très importante et, dans le cas de la vidéo, la capacité de distribuer les données en mode isochrone (à débit constant). Ni le SGBDR, ni la base à objets du groupware ne sont capables d'offrir le vecteur approprié pour ces types de données. Il n'en demeure pas moins que les besoins en données/informations des utilisateurs et des applications de groupware ne reconnaissent pas les limites technologiques au stockage et à la gestion des informations. Pour mieux le comprendre, il est important de faire la distinction entre une vue logique et une vue physique des informations. Afin de présenter aux utilis ateurs et aux applications de groupware une vue logique cohérente des informations, la base à objets doit constituer le point d'intégration des diverses sources de données. Outils de productivité bureautique. Microsoft a défini le standard OLE (Object Linking and Embedding) et DDE (Dynamic Data Exchange) pour sa famille de systèmes d'exploitation Windows. Un consortium constitué d'Apple Computer, IBM/Lotus Development et Novell a progressé dans la définition d'OpenDoc, standard d'intégration de données multi-platesformes faisant appel au System Object Model d'IBM. La base de données communes doit être conforme à ces standards pour garantir l'intégration la plus large avec les produits bureautiques. Internet et autres réseaux publics d'information. L'une des mémoires les plus riches d'informations semi-structurées se trouve dans les groupes de discussion et dans les pages World Wide Web d'Internet. Ces informations représentent des connaissances aussi essentielles pour l'entreprise que les notes de service et les bases de discussion. Par conséquent, une infrastructure moderne et complète de groupware doit fournir un moyen d'exploiter ces connaissances. Les ressources d'Internet doivent apparaître comme natives à l'utilisateur du groupware et, à l'inverse, l'utilisateur doit pouvoir publier des informations de groupware en natif, directement sur le réseau public.

35


8.7 Sécurité Les messageries et autres mémoires de données semi-structurées font habituellement appel à une force certes appropriée, mais assez primaire, que l'on appelle le système de sécurité. La plupart des informations d'un fichier de messages ou d'un outil de productivité personnelle sont par nature personnelles. C'est-à-dire que les messages contenus dans la boîte aux lettres d'un utilisateur et les documents stockés sur le disque dur du micro-ordinateur sont la propriété de chaque utilisateur. Pour garantir que seul le propriétaire de ces informations y a accès, le système de sécurité doit seulement les protéger contre tout accès non autorisé au fichier des messa " ges. De même, toutes les informations circulant sur un réseau public tel qu'Internet ou un service commercial en ligne sont disponibles pour tous les utilisateurs autorisés. Il suffit d'avoir un accès autorisé au service. Pour chacun de ces types de gestion de données, des mots de passe personnels servent depuis longtemps à protéger les données contre tout accès non autorisé. Le groupware, par contre, utilise une base à objets sous-jacente dont les utilisateurs extraient des informations. Par opposition à la ressource personnelle du fichier de messages, il s'agit d'une ressource organisationnelle partagée, qui contient normalement des informations sensibles et exclusives. L'information qu'elle contient exige par conséquent un modèle de sécurité plus évolué qui limite l'accès au système, mais contrôle aussi des niveaux d'accès plus détaillés, par plusieurs couches de mécanismes de sécurité : authentification, pour l'accès au système global, contrôle d'accès, qui définit plusieurs catégories d'accès utilisateur aux documents et aux informations, chiffrement au niveau du document et du champ, qui les protège contre toute visualisation non autorisée. De plus, puisque la messagerie continuera à servir à partager des informations sensibles, elle devra être entièrement fiable. L'intégrité des messages individuels, en termes de contenu et d'auteur, doit être protégée. Les signatures numériques, fondées sur la même technologie de chiffrement que l'authentification, sont le quatrième niveau de sécurité utilisé par une plate-forme de groupware intégrée. 8.7.1 Authentification La capacité d'établir l'identité des utilisateurs et des serveurs constitue la pierre angulaire d'un système fiable et les fonctionnalités des autres services de sécurité reposent sur la fiabilité du service d'authentification. L'état de l'art est actuellement une authentification reposant sur des certificats et le chiffrement le standard de fait de l'industrie, pour l'accès aux annuaires X.500 est le certificat X.509 fondé sur la technologie de chiffrement par clé publique RSA, reconnue comme le seul système de chiffrement fiable. Le chiffrement s'opère ainsi l'utilisateur est détenteur d'un certificat (fichier ID) qui l'identifie par son nom, son mot de passe, son numéro de licence et sa clé de chiffrement privée. Cette clé a une contrepartie, la clé publique, stockée dans un carnet d'adresses accessible publiquement. Il est virtuellement impossible d'obtenir par un calcul mathématique la clé privée de la clé publique. Lorsque l'utilisateur demande l'accès à un serveur, le processus ci-après permet de l'authentifier.

Le serveur envoie un numéro aléatoire au poste de travail de l'utilisateur. Le client chiffre ce numéro avec la clé privée de l'utilisateur, résidente sur le poste de travail. Le résultat est envoyé au serveur.

36 Groupware


Le serveur déchiffre le numéro au moyen de la clé publique de l'utilisateur, résidente dans le répertoire du serveur. Si les numéros correspondent, l'utilisateur est authentifié et peut accéder au serveur.

8.7.2 Contrôle d'accès Certains doivent pouvoir visualiser des informations ou des bases entières, sans toutefois pouvoir accéder à d'autres éléments d'informations plus sensibles. L'administrateur système doit ainsi pouvoir affecter différents niveaux d'accès à différents groupes ou individus. y compris l'accès aux bases. aux documents et aux champs des documents. L'accès à chaque ressource peut être encore plus détaillé : capacité d'entrer, de lire, d'écrire, de modifier ou de supprimer des objets. Le contrôle d'accès doit être assez flexible pour traiter les différents modes d'un utilisateur. Par exemple, lorsqu'il utilise le poste du client sur le réseau, l'utilisateur doit avoir un accès gestionnaire à une base. mais lorsqu'i1 se connecte à une base depuis un client téléphonique, où l'authentification n'est pas possi ible, l'utilisateur peut n'obtenir qu'un accès lecteur. 8.7.3 Chiffrement au niveau du champ et du document Il peut arriver qu'un utilisateur ait besoin de partager avec un autre des informations de niveau champ, tout en veillant à ce qu'aucun autre utilisateur ne puisse les visualiser. Le contrôle d'accès permet de limiter l'accès de niveau champ à certaines catégories d'utilisateurs (lecteurs, gestionnaires, etc.), mais pas à des personnes. Par conséquent, pour les informations sensibles, le concepteur de la base peut chiffrer les données avec la clé publique des lecteurs autorisés. Par ce biais, seuls les utilisateurs dîsposant de la clé privée correspondante pourront lire ce champ chiffré. Ce chiffrement sert aussi entre les serveurs, pour permettre la lecture de documents ou de champs particuliers seulement au(x) serveur(s) autorisé(s). 8.7.4 Signatures numériques L'utilisateur doit souvent vérifier que les informations reçues ont effectivement été envoyées par l'expéditeur indiqué sur le document. Il doit aussi être sûr qu'aucune des informations du document n'a subi de modification non autorisée. Ce contrôle s'effectue par les signatures numériques. Lorsque l'utilisateur A signe numériquement un message, un algorithme mathématique chiffré, le digest, est créé et annexé au message au moyen de la clé privée de l'utilisateur A. L'utilisateur B reçoit le document chiffré et déchiffre le digest au moyen de la clé publique de l'expéditeur (disponible dans le carnet d'adresses public), puis le recalcule avec les données du message. Si les deux digests correspondent, l'identité de l'expéditeur est validée. Par cette méthode, l'utilisateur B est certain que le document a effectivement été envoyé par l'utilisateur A et que personne n'a intercepté le document en chemin.

8.8 Carnets d'adresses Une des composantes principales d'un système de groupware est le carnet d'adresses, qui garde à jour les informations sur les utilisateurs et les ressources. Faisant partie intégrante de la base objets du groupware, il hérite des mêmes services système que la base elle-même, ce qui le distingue du carnet d'adresses des messageries relativement simples et ce, de trois façons : il inclut des données en plus du nom et de l'adresse, il peut stocker des informations sur des ressources autres qu'humaines, il peut être répliqué sur tout le réseau distribué. Pour garantir l'intégration et l'interopérabilité avec d'autres carnets d'adresses, celui du groupware doit être compatible avec l'architecture X.500. Il doit être aussi une riche source

37


d'informations, ce qui lui confère un rôle plus étendu que les pages blanches et les pages jaunes qui n'indiquent que le nom et la position des employés. Plus spécifiquement, ils doivent gérer les éléments suivants : • Texte riche. Faisant partie de la base à objets, les carnets d'adresses et leur contenu bénéficient du même support du texte riche que les autres documents. Un document Carnet d'adresses peut donc contenir des objets comme : imacres et voix de l'utilisateur, objets intégrés, tableaux. • Champs définis par l'utilisateur. Les informations de carnet d'adresses doivent être définissables par l'administrateur système ou l'utilisateur final. En définissant certains champs, les utilisateurs obtiennent une vue des données, privée ou personnelle, qui n'est pas nécessairement disponible pour les autres utilisateurs du carnet d'adresses. • Documents liés. Etant un document de la base à objets, le carnet d'adresses doit gérer la création de liens pointant vers d'autres documents de la base, pour permettre aux administrateurs de rattacher des informations, descriptions ou explications, à une entrée du carnet d'adresses, sans consommer plus de mémoire. Les documents liés évitent de recourir à des carnets d'adresses séparés, maintenus par plusieurs détenteurs des ressources de carnet d'adresses. Le carnet d'adresses doit contenir des informations sur les utilisateurs, mais aussi sur les autres ressources de l'entreprise. Il fait donc office de source d'informations pour les utilisateurs et pour le système. • Systèmes. Dans quelques applications, le message n'est pas destiné à une personne mais à un serveur, un télécopieur, un téléphone ou un autre destinataire électronique. Les adresses de ces ressources peuvent être conservées dans un carnet d'adresses. • Listes de diffusion. Les listes de diffusion électroniques peuvent être conservées dans le carnet d'adresses, élargies à la diffusion par courrier électronique ou par télécopie. • Certificats à clé publique. Le carnet d'adresses est un lieu approprié à la conservation des certificats à clé publique. Les applications sécurisées faisant appel à ce type de technologie nécessitent une mémoire pour les clés publiques pour la validation des signatures numériques et le chiffrement du contenu des messages, entre communautés d'utilisateurs. • Rôles. Les carnets d'adresses sont capables d'associer les personnes avec des rôles organisationnels utilisables dans les processus de workflow , les applications de workflow peuvent alors utiliser les rôles au lieu de personnes spécifiques. Les processus de workflow deviennent beaucoup plus facilement gérables lorsque les personnes sont en congé ou lorsqu'elles changent de fonction. • Tables de routage et listes de réplication. Le parcours suivi par un message entre les «hubs» et les routeurs est souvent déterminé par des considérations de disponibilité et de coût, qui varient en fonction de l'heure, de l'urgence du message, etc. Chaque entrée du carnet d'adresses doit pouvoir inclure des informations descriptives de la logique de routage, qui accompagnent en permanence cette adresse, assurant un transport opportun et efficace. De la même manière, lorsqu'une réplication est initiée (selon une certaine périodicité, ou à la

38 Groupware


demande de l'administrateur), le réplicateur cherche l'emplacement de ses homologues et détermine le trajet le plus efficace pour établir la connexion (via une connexion LAN, un appel téléphonique, etc.). Le carnet d'adresses du groupware hérite aussi des fonctionnalités de réplication du système global. La réplication facilite considérablement la synchronisation des carnets d'adresses. D'abord, il s'agit d'un processus bidirectionnel et tout changement apporté au carnet d'adresses, sur tout serveur, est automatiquement synchronisé pendant la réplication, qui prend en compte toutes les modifications, suppressions et ajouts aux deux extrémités de la connexion, par opposition à une propagation de carnet d'adresses, qui ne transmet les changements que dans un sens, écrasant toute modification apportée dans le carnet d'adresses destinataire. Ensuite, parce que les carnets d'adresses représentent souvent de vastes bases, et de ce fait, nécessitent d'importantes ressources réseau pour leur réplication dans toute l'entreprise. La procédure de réplication doit donc reconnaître les champs du carnet d'adresses qui ont été modifiés, ajoutés ou supprimes, et ne répliquer que ces changements. Aussi la réplication de la base complète (ou du classeur) ne ferait-elle que surcharger inutilement les ressources du système.

39


9 Quelques mots sur Lotus Corp. Fondée en 1982, Lotus Development Corporation est une filiale à 100% de IBM. Lotus propose des logiciels et des services de support de qualité, témoins du fait que la société est parfaitement sensibilisée aux nouveaux modes de collaboration des personnes et des entreprises. L'approche innovante de Lotus s'est traduite par une nouvelle classe d'applications permettant d'accéder à l'information et de communiquer comme jamais auparavant, à l'intérieur et à l'extérieur des frontières d'une organisation. Lotus offre une gamme complète d'applications pour les environnements Windows, OS/2, DOS, Macintosh, NT, UNIX et OS400. Lauréats de nombreux prix, les produits Lotus sont faciles à utiliser et, qui plus est, à utiliser ensemble.

9.1 Notes Domino en quelques mots Lotus Notes est le produit leader intégrant messagerie et groupware. On remarque (et c'est paradoxal) que les analystes, les clients, les partenaires commerciaux et les concurrents ont du mal à s'entendre sur la véritable nature de Notes. Il a été décrit tour à tour comme plate-forme client/serveur pour le développement et le déploiement d'applications de groupware, plate-forme d'applications hautement spécialisées, environnement ouvert permettant à des développeurs de logiciels indépendants d'intégrer leurs propres produits. Notes est un produit aux multiples facettes. Beaucoup ne voient de Notes que les applications qu'ils visualisent et exécutent dans l'environnement Notes, bases courrier, bases forum, etc. Mais la puissance de Notes réside Justement dans le fait que ces applications ne sont que de simples exemples de la large gamme que l'on peut composer avec Notes. Il n'existe pas à proprement parler un forum électronique Notes, mais de très nombreux exemples de forums électroniques pouvant être écrits avec Notes, car Notes est, dans son essence, un environnement de développement d'applications. Bien souvent, une personne va partir d'une application forum existante, ajouter des champs dans les masques, ajouter une structure dans un but spécifique (par ex. les informations sur une demande client, la saisie des données détaillant cette demande (son niveau d'urgence, etc.). Une fois ces modifications faites, et c'est facile, on obtient une nouvelle application forum adaptée à un type de collaboration spécifique. Ces applications exploitent toutes les services sous-jacents de la plate-forme Notes : messagerie, base objets, réplication, sécurité et outils de développement. La technologie Notes joue le rôle de plate-forme de groupware flexible, ou encore de cadre général permettant de bâtir et de déployer des applications de groupware. Dès sa naissance, Lotus Notes a associé trois puissantes technologies d'aide aux groupes - la messagerie, la base objets répartie et un riche environnement de développement d'applications. Elles forment une architecture modulaire, fondement d'une vaste gamme d'applications de groupware. Seul parmi les systèmes de groupware, il a fondé le groupware sur un modèle de bases de données - aussi bien comme métaphore utilisateur sous-jacente qu'au niveau des outils de conception accessibles à l'utilisateur final et aux informaticiens. Il offre à l'utilisateur final des outils de personnalisation, qui facilitent la modification simple de la structure des données et des vues des bases. Mais il offre aussi Un ensemble puissant d'API destinés aux développeurs souhaitant construire des interfaces utilisateur différentes en exploitant également le modèle des bases de données. La technologie de base répartie constitue aussi une innovation inégalée.

40 Groupware


Lotus Notes est toujours très en avance sur tous les autres produits de groupware. La puissante réplication de Lotus Notes, même sur les réseaux à connexion occasionnelle, a permis son déploiement à un moment où peu d'organisations avaient achevé la mise en oeuvre totale de leurs réseaux d'entreprise. Elle a également anticipé le besoin croissant d'une utilisation véritablement déconnectée sur les stations de travail et sur les portables. Toute une communauté d'éditeurs de logiciels indépendants, d'intégrateurs de systèmes, de développeurs d'applications et de consultants s'est construite autour de Notes. Lotus continue de cultiver cette communauté, veillant à ce que les clients aient à leur disposition les ressources leur permettant d'installer, de développer, de déployer et de aérer leurs applications écrites avec Notes. Notes contient aujourd’hui quatre composantes : Domino qui est la partie serveur, Lotus Notes qui est la partie cliente, mais pouvant être remplacé par un browser Web, Domino Administrator qui sert à administrer les serveurs depuis un micro, Domino Designer qui sert à concevoir des bases Notes.

9.2 Présentation des applications Notes Lotus Notes est un système décentralisé de gestion de base de données de documents. C'est un produit de communication et de collaboration de groupe permettant aux utilisateurs d'accéder, de retrouver, de partager et d'organiser l'information d'une manière novatrice. Les applications Lotus Notes:

• permettent aux groupes d'individus de travailler ensemble en leur donnant les moyens de créer, de consulter, de partager des informations organisées en documents, et ce par l'intermédiaire de réseaux locaux, de réseaux ouverts, &Internet ou de liaisons commutées. • leur facilitent le suivi et la structuration de ces informations, de manière originale et novatrice, même s'ils ne se connectent qu'occasionnellement à un réseau.

9.2.1 Les applications Notes Une application Notes est une mise en oeuvre de données et de programmes destinée à soutenir une fonction ou un projet professionnel (ou encore un ""processus d'entreprise"). Grâce à des applications Notes, nous pouvons créer, communiquer, partager et suivre des informations structurées en documents par l’intermédiaire de réseaux et de liaisons téléphoniques commutées. Les utilisateurs accèdent à ces informations dans le cadre d'applications qui se composent d'une ou de plusieurs bases de documents. 9.2.1.1 Les différents types d'application Notes En général, les applications Notes relèvent d'un (ou de plusieurs) type d'applications suivant:

• Gestion des flux de travail Systèmes décisionnels de groupe et support de réunions; applications de routage d'informations.

41


• Diffusion d'informations Gestion des documents de groupe, facilité d'accès aux informations les plus récentes.

• Informations de référence Utilitaires de groupes et outils de développement, accès interactif à des librairies référentielles dont les informations sont partagées et peuvent être remises à jour à tout moment.

• Suivi et circuits Gestion de flux de travail et ensemble de fonctions professionnelles pour le suivi de projets, de performances ou de tâches et pour rendre compte du statut d'un processus, d'une relation ou d'une activité, impliquant en général, plusieurs utilisateurs.

• Discussion Partage d'informations et système de conférence, support de communication de groupe, et recherche de consensus.

9.2.1.2 Flux et groupes de travail L'aspect flux de travail intervient de manière importante dans de nombreuses applications Notes. Vous pouvez inclure des fonctionnalités à n'importe lequel des grands types d'applications pour automatiser des tâches routinières, comme l'envoi de rappels ou la demande de visa. Les applications de travail en groupe peuvent même déborder les limites du groupe de travail ou de l'entreprise et inclure revendeurs, fournisseurs et sous-traitants. 9.2.2 Notes et les bases de données relationnelles Comparaison Lotus Notes et les bases de données relationnelles (RDMS) sont complémentaires, car conçus pour élaborer certains types d'application. En comprenant leurs différences, vous serez mieux à même de décider si une application nécessite Notes. Le tableau suivant résume leurs points distinctifs Bases de données relationnelles Lotus Notes Modèle: traitement de transactions Modèle : organisation de documents Utilisent des données structurées Utilisent des éléments de données semi-

structurés (texte enrichi, graphiques, etc.) Offrent un accès en temps réel aux données Font appel à des réplications périodiques

pour la mise à jour Présentent les données sur requête ad hoc Présentent les données dans des vues

(requêtes prédéfinies) Sont centralisées au sein d'une entreprise Permettent de partager des ressources entre

plusieurs entreprises Accès par SQL Accès par recherche documentaire Notes et RDMS travaillent ensemble Notes et les bases de données relationnelles ne sont pas mutuellement exclusifs. Ils peuvent échanger des données, ce qui permet d'envisager des applications évoluées. Ainsi, un manager peut se servir de Notes pour créer un rapport mensuel d'activité à partir de chiffres extraits d'une base de données.

42 Groupware


9.2.3 Notes et Internet Les applications Notes peuvent s'utiliser de manière très efficace sur Internet. Avantages des applications Domino Les applications Notes Internet (applications Domino) offrent les avantages suivants:

Sécurité - Offre toutes les fonctionnalités des applications Notes Organisation - L'information est structurée en masques et vues sur Internet comme dans le mode natif Notes Facilité d'utilisation - Offre un accès aisé et confortable à rutilisateur dans un environnement où la manipulation des nombreux outils exige souvent une très grande expertise technique Intégration RDMS - Fournit un point d'entrée frontal aux applications centralisées (ordinateur central)

Avantages pour les utilisateurs du Web Les utilisateurs naviguant sur le Web :

• disposent d'un accès interactif à un serveur Notes pour créer, modifier et effacer des informations; • accèdent de manière sécurisée aux données Notes; • utilisent les fonctions de navigation natives de Notes, telles que les vues qui peuvent être détaillées et condensées ; • Créent, modifient et suppriment des documents dans une base de données Notes.

Avantages pour les développeurs L'environnement de développement d'applications Domino offre :

• la définition par programmation du stockage des données (via des bases Notes) ; • des fonctions de recherche documentaire, avec indexage automatique; • le développement d'applications intégrées; • la messagerie et le flux de travail l'intégration de l'entreprise la réplication Notes.

Les applications interactives Web Domino :

• délivrent un contenu dynamique en fonction du temps, de l'identité, du niveau d'accès de l'utilisateur, et du type de client ; • desservent des applications de collaboration telles que des enchaînements entre documents; • étendent l'accès RDMS ; • rationalisent et automatisent les processus professionnels à l'aide d'applications de type flux de travail; • proposent des bases de documents pour l'édition décentralisée ; • utilisent le moteur de recherche documentaire de Notes permettant aux utilisateurs Web de soumettre des requêtes à une base de données Notes ; • étendent le Carnet d'adresses public de Notes au Web via l’authentification des clients Web; • le contrôle d'accès des clients Web (du niveau base de données jusqu'au niveau champ).

Les applications de sécurisation Notes offre des fonctionnalités de sécurisation sur Internet qui :

43


• protègent les informations professionnelles à travers Internet ; • facilitent pour les utilisateurs autorisés le contrôle de l'accessibilité à l'information privée ; • vous offrent des fonctionnalités de sécurité qui lui sont uniques; • appliquent au Web le modèle de contrôle d'accès Notes.

9.2.4 Définition des applications Notes 9.2.4.1 Les circonstances où Notes ne convient pas Les applications Notes sont à même de répondre aux besoins de nombreux processus d'entreprise. Mais certaines applications ne peuvent être prises en charge par Notes. Envisagez d'utiliser un autre logiciel si vous avez besoin :

• de l'accès permanent aux données en temps réel; • de très grosses bases de données (plus de 4 Go); • d'un accès aux données fondé sur les requêtes et les rapports; • de calculs complexes.

9.2.4.2 Applications et bases de documents Notes Une application Notes :

• est une mise en oeuvre de données et de programmes qui sous-tend une fonction ou un objet professionnel; • se compose d'une ou de plusieurs bases de documents.

Une base de documents Notes :

• contient des informations réparties dans des documents multiples et concernant des sujets liés ; • sert de centre d'archivage et de diffusion d'informations.

9.3 Conception d'une base de documents Notes 9.3.1 Composants fondamentaux d'une base de documents Notes En tant que développeurs d'applications, vous devez définir les éléments conceptuels de saisie, stockage et sécurisation de l'information. 9.3.1.1 Eléments conceptuels fondamentaux Une base Notes se compose de documents et d'éléments de conception de ces documents. Ces éléments de structure comportent les vues, les masques et les champs. Chaque document est un enregistrement individuel d'information. Masques Le masque est l'élément principal de la structure d'une base Notes. n s'agit d'un modèle de document qui permet de structurer la saisie des données. Une fois les données saisies dans le masque, les informations sont stockées dans un document de la base. Les champs Un champ est une zone d'un masque qui contient une unité élémentaire d'information. Chaque champ d'un masque est défini de telle sorte qu'il détermine l'information qu'il peut accueillir. Documents

44 Groupware


Un document est un ensemble de données créé par l'intermédiaire d'un masque. Les données peuvent également être placées dans un document de manière programmée, grâce à des formules. Vues Une vue s'apparente à une table des matières dynamique. Elle donne accès aux documents Notes d'une base. Les vues se composent de colonnes et de rangées qui présentent aux utilisateurs une liste des documents, avec les données des champs correspondant aux colonnes que le créateur de la vue a choisi de montrer. En tant que développeur, vous pouvez choisir de montrer tous les documents d'une base dans une vue ou seulement une partie de ces documents. Pour créer la vue, vous sélectionnez, triez et répertoriez les documents qui doivent apparaître dans la liste. 9.3.1.2 Eléments de conception pouvant être créés par un utilisateur Le menu Création propose les éléments suivants à l'utilisateur :

• Agents ;. • Dossiers ; • Vues.

9.3.1.3 Eléments pouvant être créés par le développeur Le menu Concevoir propose au développeur tout un ensemble d'éléments de conception :

• agents; • dossiers; • masques; • navigateurs; • bibliothèques de scripts; • champs partagés; • sous-masques; • vues.

Relation entre masques et documents Les masques permettent aux utilisateurs de créer des documents pour stocker les données de rapplication. Un masque contient des champs pour afficher des données, du texte et des graphiques pour le rendre plus attrayant. Eléments du masque Lors de la création d'un masque, le menu Création propose les éléments suivants:

• les actions; • les champs; • les zones de présentation; • des ajoutes de sous-masques et de champs partagés.

Eléments d'une vue Lors de la création d'une vue, le menu Création propose :

• les actions; • les colonnes.

9.3.2 Création d'une base Notes

45


9.3.2.1 Etapes de construction et de déploiement d'une application La création de la base proprement dite n'est qu'une des étapes de rélaboration d'une application Notes réussie. Les étapes de préparation, de création et de suivi d'une application Notes sont les suivantes : Etape Action 1 Définissez les besoins de votre entreprise en interrogeant les utilisateurs potentiels de l'application et en analysant les procédures et systèmes existant sur support papier ou informatique. 2 Dessinez sur papier l'organisation fonctionnelle de l'application. 3 Passez en revue l'ébauche de l’application avec ses utilisateurs et procédez aux modifications pour lesquelles ils ont marqué leur accord. 4 Créez un fichier NSF. 5 Créez le ou les masques voulus et définissez les champs servant de base à tous

les autres éléments. 6 Créez les vues en fonction des champs définis précédemment au niveau des

masques. 7 Définissez une liste de contrôle d'accès (LCA) pour spécifier quels utilisateurs

peuvent avoir accès à la base. 8 Créez un document de présentation de la base et un document d'instructions

d'utilisation de la base. 9 Documentez tout votre travail au fur et à mesure. 10 Créez l'icône de la base, qui lui donnera une identité visuelle propre . il Créez les actions, puis concevez et créez les navigateurs. 12 Utilisez cette application comme prototype et copiez-la sur le serveur.

N'accordez raccès qu'à des utilisateurs choisis pour tester la base. 13 Testez l'application et recueillez les remarques des testeurs.

9.3.2.2 Etapes de construction et de déploiement d'une application... Etape Action 14 Apportez les modifications nécessaires et ouvrez la base aux autres utilisateurs. 15 Mettez à jour les spécifications écrites de l'application. 16 Pensez à organiser une formation sur la nouvelle application dans le cadre de sa mise en place.

46 Groupware


9.3.2.3 Création d'une base Notes. Vous pouvez créer une base Notes de trois manières:

• en utilisant un modèle existant; • en copiant une base existante • en créant une base entièrement nouvelle.

Utilisation d'un modèle Un modèle de base est une sorte de stencil. Il s'agit d'une structure de base que vous pouvez copier et utiliser telle quelle ou bien l’adapter à vos besoins. Le recours aux modèles : • fait gagner du temps dans le processus de développement; • réduit les risques d'erreur; • facilite l'apprentissage de l'application aux utilisateurs qui connaissent déjà les bases issues du même modèle. Notes Version 5 (V5) est fourni avec plusieurs modèles de base, notamment :

• Discussion; • Cycle d'approbation (ou circuit signature) (Approval Cycle) • Bibliothèque de documents(Docurnents Library) • Réservation de salles(Room Réservations) • Journal personnel(Personal journal).

Copie d'une base existante La copie d'une base est utile pour :

• créer plusieurs bases complexes mais de structure similaire; • créer des bases d'archivage.

Création d'une base entièrement nouvelle S'il n'existe pas de modèle particulièrement adapté à votre application et que vous ne disposez d'aucune base du même genre, vous allez créer une base vide et définir vous même tous ses éléments de structure.