NOTERE'97 (Pau, 5 novembre 1997)

Session projets industriels







 

Réaliser un Intranet : Construction d'un Ensemble Réparti et Cohérent, autour d'une Architecture Réflexive

 

RÉSUMÉ - Un intranet permet de déployer les applications client-serveur sur l'ensemble des postes de l'entreprise. Il concerne cependant des centaines de personnes, peu familières des technologies et de l'approche hypertexte. Les problèmes de cohérence et de persistance des liens, des modèles de documents, des feuilles de style, d'administration et d'exploitation de l'ensemble, s'avèrent alors d'une acuité inconnue sur l'Internet. RICERCAR est un système réflexif qui modélise, grâce à des outils " standards ", les objets de l'utilisateur mais aussi les siens propres dans une fédération de bases de données réparties et synchronisées. Les identifiants de ces objets sont alors utilisés pour implémenter des URL stables qui assurent la cohérence globale de l'intranet. L'architecture modulaire du système offre une interface applicative permettant de l'étendre rapidement en y intégrant des données d'entreprise lesquelles, s'appuyant sur le noyau commun, bénéficient alors de la cohérence d'ensemble ainsi que des différents outils d'administration et de métrologie.

MOTS-CLEFS - utilisateur final, intranet, client-serveur, cohérence, génération dynamique, bases réparties, amorçage, modularité, réflexivité.

INTRODUCTION

Le client-serveur, fonctionnel depuis de nombreuses années, s'est néanmoins heurté au problème aigu du coût du déploiement des applications ainsi que de leur configuration sur des milliers de postes de travail hétérogènes (type, mémoire, capacité, niveau de système d'exploitation, etc.). L'appropriation des technologies du World Wide Web par l'entreprise lui ouvre un nouvel avenir.

Ce nouveau paradigme, autour duquel semble devoir s'organiser le système d'information, n'est cependant pas sans poser à son tour un ensemble de questions dont l'acuité est à l'échelle du succès attendu de l'intranet. Tant techniques que structurels et organisationnels, ces problèmes sont d'autant plus difficiles à appréhender qu'ils concernent peu l'Internet dont le polymorphisme, parfois chaotique, ne fait en réalité que refléter la diversité de culture de ses différents acteurs.

La réussite d'un intranet suppose en effet qu'une qualité de service soit assurée par une architecture et des outils modulaires, robustes mais simples. Il s'agit, à l'instar de toute application ayant pour cible l'ensemble de l'entreprise [1] de :

  • garantir la validité, la cohérence et la fraîcheur des informations publiées ;
  • assurer la pérennité de données issues d'applications plus anciennes ;
  • définir les règles permettant à un ensemble d'acteurs, de profils très variables, d'enrichir le système en minimisant les contraintes ;
  • fournir à l'utilisateur final, peu formé par définition, une ergonomie simple et évolutive ;
  • gérer les profils et droits éventuels de milliers d'utilisateurs ;
  • gérer des données dynamiques, réparties sur l'ensemble de l'entreprise ;
  • disposer de statistiques d'accès aux différents services, fiables et adaptatives ;
  • fournir aux exploitants des outils de gestion, de surveillance et d'audit.

Établi par [Black 94, Berners-Lee 94a], le parallèle entre le Web et un système d'exploitation orienté objet montre bien l'adéquation de ce modèle à la diversité, la modularité et la " transversalité " de l'Internet (et par restriction, de l'intranet), dans la mesure où il implémente naturellement la persistance des objets (création, destruction et stockage des documents), leur invocation (un protocole - HTTP - compris de tous les objets, capable de leur transmettre des messages avec des paramètres - les méthodes GET, POST, etc.), un nommage uniforme (les URL [Berners-Lee 94b]) et une extensibilité du modèle sans recompilation d'un noyau (les CGI et API).

Par ailleurs, si le foisonnement actuel des recherches autour des nombreux concepts d'objets et de composants réutilisables tels CORBA [OMG 96a], DCOM [Brown 96] ou JavaBeans [Colan 97] montre clairement l'intérêt du mariage de ces approches, il masque cependant l'absence de maturité des standards et surtout le fossé technologique qui existe entre des groupes ayant une vision prospective évoluée de l'informatique et d'autres, plus traditionnels, où la taille et la culture d'entreprise induisent des lourdeurs et une inertie inévitables.

Cet article présente ainsi une architecture de base, réflexive, orientée-objet et commune à un intranet qui associe dans sa phase actuelle le Web, les bases de données, un métalangage de manipulation de description et, dans une moindre mesure l'Intelligence Artificielle, pour proposer aux utilisateurs connectés au réseau d'entreprise un accès fiable et uniforme à un ensemble facilement extensible de données locales ou transversales.

RICERCAR met en place un ensemble de bases de données fédérées qui décrivent et référencent les objets disponibles. Les serveurs Web associés à ces bases composent ainsi dynamiquement les documents correspondants, indépendamment du serveur interrogé ou de la localisation effective de ces données. Cette architecture garantit la qualité de service en assurant notamment la permanence des URL publiées et la génération dynamique de la structure (l'arborescence) d'un serveur. Elle propose un modèle de navigation uniforme, gère l'authentification et les accès des utilisateurs et, enfin, autorise une surveillance d'ensemble ainsi que des statistiques de fréquentation modulaires et significatives.

Les différents amorçages de RICERCAR ont abouti à l'enregistrement, dans cette même base répartie, de la description et des références de ses données propres ainsi que des métascripts utilisés pour générer dynamiquement les documents de l'intranet. Cette réflexivité qui lui permet de manipuler et d'enrichir ses structures en fait ainsi un système ouvert et adaptatif.

Nous évoquerons donc les spécificités techniques et organisationnelles qui singularisent à notre sens l'intranet par rapport à l'Internet ainsi que leur implémentation dans RICERCAR dont nous citerons enfin les applications concrètes ainsi que les perspectives d'évolution envisagées.

L'INTRANET : UNE " APPLICATION " D'ENTREPRISE NORMALE

La mise en place de solutions du type intranet présente de prime abord de nombreux avantages en termes de communication interne, de travail en groupe, de partage de données, d'accès à des bases de données, etc. Elle offre aussi l'opportunité de doter à moindre coût l'ensemble des postes de travail d'un navigateur vu comme un client universel [Lefebvre 97, Sauteur 97] et permet ainsi à des centaines de personnes de contribuer activement à la diffusion des informations dans l'entreprise.

Cependant, la transposition à l'identique de l'organisation de l'Internet dans l'entreprise induirait rapidement des problèmes de fiabilité, d'incohérence et d'administration d'ensemble. En effet, la diversité et la divergence des intérêts qui s'expriment sur l'Internet s'épanouissent dans une organisation où chaque serveur représente un groupe d'expression différent. Il en est autrement dans un réseau d'entreprise, qui doit offrir des garanties de cohérence de contenu mais aussi de présentation à une Direction Générale, par définition méfiante à l'égard des nouvelles technologies - a fortiori de l'intranet, perçu comme une importation dans l'entreprise de l'organisation chaotique de l'Internet.

Un intranet s'adresse par ailleurs a priori à une population très différente de celle de l'Internet. Il s'agit en effet de milliers de collaborateurs, peu familiers des outils informatiques, disposant d'un poste de travail connecté à un réseau local et qui subissent l'outil de navigation comme un outil Bureautique supplémentaire venant se greffer au traitement de texte, au tableur ou à la messagerie (la dernière version du Pack Office de Microsoft suffit pour s'en convaincre).

Enfin, la communication transversale entre les différents départements est - naturellement - une communication de proximité ou inspirée par des intérêts ponctuels. Un des attendus de l'intranet est alors de contribuer à créer une synergie de communication et d'échanges. Toute perturbation (freins structurels, surcharge du réseau, mauvaise structuration des données, problèmes d'accès aux documents, lourdeur d'administration, etc.) se fera donc au détriment de l'adhésion et de la fidélisation du plus grand nombre.

Il est vraisemblable que la réussite de l'intranet ne se fera que dans la mesure où l'utilisateur considérera qu'il n'a qu'une seule " application " qui lui est proposée, le navigateur, et qu'il s'y référera naturellement pour accéder à un ensemble croissant des données de l'entreprise. Cette simplicité d'usage nécessite cependant que l'intranet soit considéré avec la même rigueur que toute autre application d'entreprise.

L'INTRANET : UN CHANTIER SOCIAL

Aux multiples questions techniques et d'architecture posées par la réflexion autour d'un intranet s'ajoutent des problèmes sociaux, organisationnels et humains, absents de l'Internet [Dufour 96, Augendre 97].

Il nous semble important d'en recenser quelques uns [Alin 97, Bitouzet 97] pouvant, séparément, freiner le déploiement effectif d'un intranet et qui, combinés, s'avèrent quasi insurmontables :

  1. faible technicité des cadres dirigeants et mauvaise perception des concepts en jeu (notamment le client-serveur ) ;
  2. équipes d'étude et de développement réduites à la portion congrue après plusieurs années de politique de sous-traitance des projets informatiques ;
  3. consultation systématique d'intervenants externes qui, d'une part, ne sont pas mandatés pour assurer une cohérence entre leurs différents sujets d'intervention et, d'autre part, n'ont souvent pas d'expérience de solutions intranet et tentent de plaquer telles quelles leurs études basées sur l'Internet ;
  4. inadéquation de la réactivité des circuits décisionnels de l'entreprise par rapport à l'évolution des produits ;
  5. contraste entre tenants d'un intranet à l'image de l'Internet (libertés de publication et d'accès totales) et tenants d'un intranet rigidifié avec circulation des flux déterminée et contrôlée. Une proposition qui tend à laisser les utilisateurs s'exprimer avec souplesse dans un cadre institutionnel a ainsi toutes les chances de rallier contre elle les partisans de ces deux camps ;
  6. répugnance de l'entreprise à adopter un modèle de développement en spirale [Boehm 88] et, par conséquent, extrême méfiance vis-à-vis de la rapidité des réalisations (quelques heures pour un premier prototype) ;
  7. remise en cause de circuits séculaires de communication (la hiérarchie intermédiaire notamment) inadaptés à une nouvelle organisation centrée autour d'un accès simplifié à l'information [Adams 97, Berger 97, Bossard 97].

C'est néanmoins convaincu du déploiement inéluctable d'un intranet à brève échéance, que nous insistons ici sur l'opportunité apportée au Système d'Information de l'entreprise de mettre rapidement au point une palette technique qui assure aux divers interlocuteurs (utilisateurs finals, auteurs à la source de l'information, administrateurs, informaticiens, responsables et Direction Générale) des mécanismes simples et robustes de consultation et de publication d'informations cohérentes et fiables. Il s'agit notamment d'éviter une prolifération anarchique de serveurs - emballée par la sur-médiatisation actuelle de l'Internet qui assure le tout-venant de l'extrême simplicité de mise en œuvre, de publication et d'administration d'ensemble.

Les mécanismes dont nous ébauchons la description ci-après se justifient pour un ensemble de serveurs répartis. Il est en effet relativement aisé de gérer une cohérence locale à un serveur sans pour autant devoir s'embarrasser d'architecture complexe (FrontPage de Microsoft propose par exemple une solution séduisante mais non généralisable à un réseau). C'est toutefois un cadre global d'un réseau de serveurs et de milliers de postes de travail, où une cohérence locale n'implique pas de cohérence globale, qu'une fédération de " dictionnaires " permet de référencer la création, la modification ou le déplacement d'un objet d'un quelconque serveur du réseau à un autre de façon transparente pour l'utilisateur final [Séraphin 97].

Et c'est dans ce cadre que RICERCAR est en cours d'évaluation à la RATP et à l'Université René Descartes.

L'INTRANET : IMPACTS SUR L'ARCHITECTURE

Cohérence des liens hypertextes (inter- ou intra-serveurs)

La création d'un document sur un Web correspond à la création d'une nouvelle URL, référencée ensuite " manuellement " dans un fichier particulier du répertoire, faisant office d'index (généralement un fichier index.html). La publication de ce document a deux conséquences naturelles :

  1. être consulté par un nombre indéterminé de personnes qui s'approprient l'information en mémorisant l'URL du document dans leur répertoire personnel (bookmark) pour y accéder ultérieurement ;
  2. être cité (lien hypertexte) par un ensemble indéterminé d'autres documents tant internes (physiquement sur le même serveur) qu'externes (localisés sur d'autres serveurs).

Il est alors évident que toute modification, que se soit un déplacement dans l'arborescence du serveur, un changement de serveur, de nom ou d'extension, un archivage ou une modification du nom ou même éventuellement de l'adresse IP du serveur, entraînent, sur un serveur HTTP traditionnel, une modification de son URL qui rend caduques l'ensemble des références établies.

Une modification de structure du serveur provoque une erreur lors de l’accès aux documents.
Une modification de structure du serveur provoque une erreur lors de l’accès aux documents.

Peu prégnant aux débuts du Web, ce manque de robustesse du nommage (tout au moins de son interprétation), préoccupe une frange croissante de la communauté de l'Internet. Celle-ci, dans une série de recommandations [2] relatives au nommage et à sa philosophie, précise dans un premier temps que " la similarité avec une arborescence physique telle celle d'UNIX ou d'un autre système d'exploitation doit [3] être considérée comme étant une pure coïncidence et ne doit pas être exploitée pour interpréter des URI [4] comme étant des noms de fichiers " [Berners-Lee 94a, p.6]. Elle définit dans le même temps une URL comme " une forme d'URI qui exprime une adresse définie par un algorithme d'accès calculé par des protocoles réseau " [Sollins 94] [Berners-Lee 94a, p.1], puis précise " qu'un nom de ressource suppose la définition d'un pointeur stable qui continue à référencer cette ressource longtemps après qu'elle a changé de localisation ou même cessé d'exister " [Kunze 95, p.1].

La presse spécialisée se fait elle aussi l'écho des problèmes induits par l'accroissement et la dynamique des serveurs HTTP [Bitouzet 97, Dhénin 97, Hower 97] tant il est désormais banal de constater sur un Web (qu'il soit de type Internet ou intranet) que des liens ne sont plus à jour ou que l'interrogation de moteurs de recherche pointe sur des pages qui n'existent plus ou ont été déplacées ; il est aussi fréquent de constater que certaines informations manquent de fraîcheur. L'ensemble de ces dysfonctionnements est généralement à mettre sur le compte de la complexité de maintenir une arborescence physique de fichiers de plus en plus touffue.

Sachant que l'ensemble des liens pointant sur un document donné ne peut être déterminé, une seule solution garantit qu'un lien permettra toujours d'y accéder, s'il existe : figer ce lien, donc figer l'URL de l'objet.

Cette cohérence peut se traduire concrètement de deux manières :

  1. ne jamais modifier un lien publié (les limites sont évidentes) ;
  2. modifier l'interprétation d'une URL [Kunze 95] en la considérant comme un identifiant de référenciel unique d'un objet [OSF 93, OMG 96a] ; cet identifiant peut notamment servir à en calculer la localisation exacte (un pointeur vers le fichier ad hoc) mais peut surtout correspondre à une méthode permettant de le construire dynamiquement.
  3. Il suffit ensuite de répercuter les modifications dans un dictionnaire (combinaison des Référentiels d'Implémentations et d'Interfaces) lors des mises à jour (déplacement, changement de nom, d'extension, de version, etc.) pour que les accès soient maintenus en toute transparence pour l'utilisateur.
Une modification de l’objet (ici un pointeur physique) modifie ses métadonnées dans le dictionnaire de façon transparente pour l’utilisateur final.
Une modification de l’objet (ici un pointeur physique) modifie ses métadonnées dans le dictionnaire de façon transparente pour l’utilisateur final.

Interface des objets " pages "

La création des pages d'information (les documents HTML notamment) peut ainsi employer les outils traditionnels de conception. L'auteur, désirant se référer à un objet local ou distant, l'associe par un lien hypertexte à l'identifiant de référentiel correspondant, représenté sous forme d'une URL absolue ou relative [Fielding 95], formellement identique à une URL standard.

L'activation du lien engendre une requête au dictionnaire qui permet la récupération des métadonnées de l'objet, identifie dynamiquement sa classe et invoque alors la méthode ad hoc pour construire le document final.

L’auteur d’un document insère des liens vers des IDentifiants de Référentiel globaux, représentés par des URL. L’activation d’un lien permet de retrouver dynamiquement, à partir du dictionnaire, la méthode à invoquer pour construire le document correspondant.
L’auteur d’un document insère des liens vers des IDentifiants de Référentiel globaux, représentés par des URL. L’activation d’un lien permet de retrouver dynamiquement, à partir du dictionnaire, la méthode à invoquer pour construire le document correspondant.

Interface des objets " index "

La description exhaustive des objets et de leurs relations dans un dictionnaire est en surjection avec la représentation arborescente normale d'un serveur HTTP (racine, index, feuilles). L'activation d'un " menu " (anciennement index.html) extrait du dictionnaire la liste des objets qui lui sont liés par une relation du type " a-pour-père " et invoque alors une méthode permettant de formater et générer à la volée la représentation de ce menu. Cette automatisation affranchit ainsi le gestionnaire de la contrainte de répercuter les modifications dans un fichier index.html et garantit que toute mise à jour est immédiatement proposée aux utilisateurs.

L’auteur d’un document insère des liens vers des IDentifiants de Référentiel globaux, représentés par des URL. L’activation d’un lien permet de retrouver dynamiquement, à partir du dictionnaire, la méthode à invoquer pour construire le document correspondant.
L’auteur d’un document insère des liens vers des IDentifiants de Référentiel globaux, représentés par des URL. L’activation d’un lien permet de retrouver dynamiquement, à partir du dictionnaire, la méthode à invoquer pour construire le document correspondant.

Cohérence de la navigation

L'implémentation du dictionnaire n'assure toutefois qu'une cohérence locale à un serveur donné. Une fédération de référentiels d'interfaces assurée par une métabase (un index des dictionnaires [Gardarin 90, Orfali 95]) permet d'étendre cette cohérence à l'ensemble de l'intranet, vu alors comme un seul serveur virtuel, union de tous les serveurs. Elle nécessite toutefois l'attribution d'un identifiant unique par serveur, utilisé pour préfixer les identifiants de référentiels des objets. Les classes et opérations globales, répliquées sur l'ensemble des serveurs, sont quant à elles singularisées par un identifiant spécifique (celui du serveur global virtuel).

Une réplication et une synchronisation d'un ensemble de tables de cette métabase sont ensuite effectuées sur chacun des serveurs. Elles présentent deux avantages notables :

  1. créer une redondance qui permet de réduire le trafic induit sur le réseau pour localiser les objets ;
  2. pallier les défaillances ponctuelles des serveurs (pannes ou perturbation du réseau) et éviter des goulets d'étranglement.

L'unicité des interfaces, garantie par-delà des serveurs, permet ainsi à un utilisateur de requérir n'importe quel objet de n'importe quel serveur du réseau. Celui-ci extrait les métadonnées correspondantes de son dictionnaire qui lui indiquent, le cas échéant, l'identifiant du serveur distant auquel il retransmet la requête de l'utilisateur pour extraire les métadonnées supplémentaires nécessaires à la construction de l'objet..

La fédération des dictionnaires assure la cohérence globale de la navigation. La requête d’un objet est automatiquement acheminée vers le serveur ad hoc.
La fédération des dictionnaires assure la cohérence globale de la navigation. La requête d’un objet est automatiquement acheminée vers le serveur ad hoc.

Cohérence de la présentation des données

L'impossibilité de former les utilisateurs de l'entreprise préalablement à la publication de toute nouvelle application sur un Web justifie qu'un modèle de navigation intuitif et uniforme soit proposé (positionnement et sémantique stables des éléments graphiques tels les retours aux sommaires, les logos d'application, les coordonnées des auteurs et gestionnaires des données, etc.). En l'absence de telles règles, les documents sont - au mieux - produits sous autant d'aspects différents qu'il y a de départements, au prix d'une dégradation de l'ergonomie et d'une impression globale d'anarchie.

La solution généralement retenue dans une grande entreprise, soucieuse de formaliser et d'homogénéiser la diffusion des informations à ses utilisateurs, consiste à " suggérer " l'usage de modèles de documents et d'une charte graphique. Il est néanmoins courant, au regard des contraintes imposées, que ces modèles restent l'apanage de quelques puristes ou spécialistes des outils de publication et soient ignorés de la majorité des collaborateurs de l'entreprise (il suffit de compter le nombre de secrétaires, professionnelles du traitement de texte, qui font pourtant un usage limité des feuilles de style).

La création de modèles (héritant d'une classe abstraite) permet cependant d'appliquer une charte graphique avec un minimum de contraintes. L'auteur dispose d'une feuille de style réduite qui assure la conversion en HTML de documents issus d'un traitement de texte (niveaux de titres, listes à puces ou numérotées). La réification de ces documents, par le biais d'automates ou de formulaires de publication, se ramène alors à instancier une de ces classes.

L'invocation d'un objet permet d'extraire du dictionnaire la description du (méta) modèle associé [Briot 87], utilisée alors pour générer dynamiquement le document HTML final, dont la présentation (fond, logos, en-tête, signature, dates de création/modification, style [Lie 96], etc.) respectera scrupuleusement in fine la charte graphique de l'entreprise.

Cohérence de l'exploitation d'un intranet

Authentification des utilisateurs

Les différentes versions du protocole HTTP [Berners-Lee 94a, Franks 97] ne couvrent que marginalement les considérations de sécurité et d'authentification des utilisateurs. Seul un algorithme mono-serveur [5] général et de fiabilité limitée y est décrit. Son implémentation sur un intranet implique de gérer par des mécanismes externes la réplication des comptes d'utilisateurs entre les différents serveurs. Cette tâche d'administration non triviale est souvent à la source de l'incohérence des identifiants ou des mots de passe des utilisateurs et va à l'encontre des considérations attendues de sécurité et de fiabilité des accès.

La réification de l'utilisateur permet cependant de l'intégrer dans un cadre global d'authentification [OMG 96b] dont le résultat est un IDentifiant authentifié unique (créé par un serveur disposant de méthodes ad hoc), propagé automatiquement sur chacun des serveurs par le contexte d'invocation des objets. Chaque serveur dispose en outre de Listes de Contrôle d'Accès (ACL) qui maintiennent les droits de création, de modification ou d'invocation des différents objets, par utilisateur ou par groupe d'utilisateurs. RICERCAR implémente actuellement une méthode d'authentification et d'instanciation de ses utilisateurs, Sys_Acl [6], qui enregistre pour la durée de leur session sur le poste de travail, leur IDentifiant authentifié sous la forme de Cookies [Kristol 97]. Il est ainsi envisageable de remplacer si nécessaire cette méthode par une authentification à tierce partie sûre telle Kerberos [Steiner 88].

Métrologie des accès

L'extraction des statistiques de consultation d'un serveur HTTP est complexe. Bien que celui-ci écrive en permanence le détail des éléments consultés dans un fichier d'événements (fichier log), l'atomicité de ces informations, enregistrées dans un fichier texte, rend leur exploitation et leur interprétation malaisées. En effet, leur granularité reflète la complexité des documents consultés (les images, boutons, lignes et autres éléments de présentation enregistrent chacun une ligne dans les log) alors qu'il serait beaucoup plus informatif de disposer de statistiques d'accès aux différents objets. L'interpolation des hits annoncés par serveur avec un nombre de pages effectivement lues est ainsi souvent périlleuse. De plus, un navigateur dispose d'un cache qui mémorise les pages consultées afin d'optimiser les accès au réseau. Les fichiers de log ne reflètent alors plus qu'une partie des accès réels, rendant leur interprétation encore plus hasardeuse. Il n'est enfin pas prévu d'assurer le suivi d'un utilisateur sur un ensemble de serveurs.

La mise en place d'un dictionnaire permet de lier aux objets un ensemble de " macro-événements " desquels sont extraites des statistiques relatives aux objets consultés (qui, quand, combien de fois, à partir d'où, sous quel nom, etc.). Ces données peuvent être ensuite agrégées pour offrir une métrologie ou des éléments de facturation " à la carte ". L'invocation dynamique des objets permet aux administrateurs, dans le cadre de campagnes de mesure, de modifier par ailleurs les métadonnées des classes afin de forcer l'expiration du cache du navigateur et de disposer de chiffres de consultation fiables (au prix, il est vrai, d'une dégradation provisoire des performances d'ensemble).

RICERCAR : UN SYSTEME REFLEXIF

Implémentation

CGI ou API ?

Les CGI [7] [McCool 94] ont permis d'étendre les fonctionnalités des serveurs HTTP en offrant la possibilité de combiner dynamiquement des données issues de sources diverses (formulaires saisis par les utilisateurs, accès à des bases de données, etc.) pour en générer des documents HTML virtuels. Aux premières interfaces, réalisées à l'aide de programmes spécifiques en C, C++, Perl ou TK/TCL, ont succédé de nombreux métalangages structurés qui permettent désormais de concevoir des applications modulaires rendant aisés l'accès et la mise à jour de bases de données issues d'applications traditionnelles.

En dépit de leur standardisation, les CGI présentent des inconvénients tels que leur usage est incompatible avec un service performant et complexe. En effet, à l'instar du protocole HTTP, non connecté et sans état, chaque appel à une CGI crée un nouveau processus dont la durée de vie est limitée au temps d'exécution. Ce mécanisme, coûteux en ressources (CPU et mémoire), initialise donc son contexte à chaque appel et rend acrobatique la gestion de transactions. L'adoption d'API, spécifiques à chaque fournisseur de serveur HTTP, permet de circonvenir ces limites : un processus constamment actif sur le serveur, gérant un contexte global d'exécution, lance un processus fils à chaque appel de l'utilisateur, ce qui facilite ainsi l'exécution de transactions complexes.

Cold Fusion

Après avoir étudié la conception et le développement d'un outil spécifique pour l'implémentation de RICERCAR, nous avons opté (en 1995) pour le choix d'un langage commercialisé par ailleurs, Cold Fusion Markup Language (CFML) [Allaire 97], notre propos étant d'étayer une thèse sur une architecture distribuée pour un intranet et non de nous disperser dans la conception d'un langage structuré supplémentaire dont l'entreprise ne saurait assurer ni la maintenance ni l'évolution.

Ce langage particulier étend HTML par un ensemble de balises qui permettent d'interroger en SQL n'importe quelle source de données pourvue d'un connecteur ODBC [Microsoft 92] (la plupart des SGBD sous NT ou UNIX) et propose des fonctions de test et de branchement pour les traiter. Il dispose en outre de nombreuses primitives [8] extensibles, est porté sur les systèmes d'exploitation les plus répandus [9] et bénéficie d'une très grande réactivité [10] de ses développeurs. Un compilateur incrémental associé à un cache géré par le serveur, achèvent de garantir des performances stables à charge élevée.

La conception d'une application en Cold Fusion correspond à l'écriture d'un ensemble de scripts (mélange de CFML et HTML) qui vont, en fonction du besoin, quérir une base de données et générer le code HTML correspondant au résultat ou même enrichir cette base en fonction d'interactions avec les utilisateurs.

Amorçages (bootstraps) et réflexivité

L'implémentation d'un concept objet à partir d'un langage procédural qui interface des bases relationnelles peut se révéler délicate [Gardarin 90, Rumbaugh 96, Bouzeghoub 97] puisque seules les relations entre objets sont représentées par des tables. Concrètement, l'information concernant un objet particulier est dispersée (si les bases sont correctement normalisées) et ne peut être reconstituée qu'au prix de jointures multiples. De nombreuses études ont néanmoins été menées pour essayer d'accommoder des structures d'objets à des langages procéduraux ou à des formats de stockage relationnels d'autant que [Coad 91, Coulouris 95] ont, avec d'autres, souligné l'intérêt d'une approche objet au niveau conceptuel, indépendamment du fait que l'implémentation soit ou non objet (X-Window est l'exemple d'un tel environnement, totalement écrit en C [Young 90]).

En pratique, le nombre restreint des classes (une cinquantaine) ainsi que la relative simplicité du modèle d'un intranet permettent d'optimiser le placement des objets (notamment la possibilité de stocker dans le cache du serveur le résultat des jointures) et de limiter les inconvénients d'une implémentation relationnelle de RICERCAR.

Méta-amorçage

Une application distribuée doit adresser successivement des considérations relatives au nommage, à la communication entre composants, aux interfaces entre objets, à l'optimisation des performances et à la cohérence d'ensemble afin de garantir à ses utilisateurs une qualité de service ainsi que des fonctionnalités incrémentales [Coulouris 95]. Ce n'est cependant que par une série d'amorçages [Boehm 88] que nous avons réussi à implémenter ces différents concepts. Les premières versions de RICERCAR (janvier 1996) se sont en effet essentiellement attachées à définir un nommage stable afin de résoudre l'incohérence des liens hypertextes. Une fois ce problème traité de façon satisfaisante, nous avons figé ce nommage, interface externe du système, et avons ensuite, par prototypages successifs, homogénéisé la représentation des données puis enrichi la sémantique de RICERCAR en lui permettant de manipuler de façon uniforme les différentes applications de l'intranet ainsi que ses données propres, vues comme une application particulière.

L'introduction d'un niveau
L'introduction d'un niveau "" méta "" dans l'interprétation permet de représenter les métadonnées de RICERCAR dans un "" Référentiel des Interfaces ""

Amorçage de la représentation des données

Une première représentation d'un dictionnaire peut se résumer à une table qui fait correspondre l'identifiant d'un objet à un fichier. Elle s'avère cependant rapidement limitée dans la mesure où elle se ramène à l'intégration (même automatisée) de code CFML dans les documents HTML des utilisateurs. Cette équivalence de facto entre un script et un objet réduit la modularité, la portabilité et l'intérêt même de cette approche.

Il nous a alors semblé nécessaire d'introduire un niveau d'abstraction supplémentaire en identifiant des classes de documents, décrites et enregistrées dans des tables ad hoc du dictionnaire (promu pour l'occasion en base de métadonnées). Il devenait alors possible d'associer à chaque classe un métascript (une méthode assurant la génération du code HTML final) qui recevrait en paramètre la référence d'un objet.

La généralisation des propriétés communes à ces classes dans une métaclasse abstraite (correspondant à la réification de la charte graphique de l'entreprise : entête, signature, logos, éléments de navigation, etc.) a finalement permis de référencer uniformément ces classes dans le dictionnaire, dans un modèle " tout objet " [Briot 87].

Finalement, le dictionnaire implémente un concept
Finalement, le dictionnaire implémente un concept " tout objet " en référençant indifféremment tous les documents (pages HTML, scripts et métascripts CFM) eux-mêmes composés de sous-"documents".

Amorçage de l'utilisation des métadonnées

[Pitrat 90] détaille comment l'usage d'une représentation unique pour les connaissances et les métaconnaissances permet de limiter la hiérarchie des niveaux méta (en spécialisant ces différentes " connaissances " selon le rôle qu'elles jouent à un moment donné). C'est ainsi que la représentation uniforme dans le dictionnaire des objets et de leurs classes (resp. des scripts et métascripts) nous a permis de considérer ce dictionnaire comme une base de données " normale ". Il ne restait plus alors qu'à considérer l'ensemble des (méta) scripts de RICERCAR comme formant une application intranet " normale " qui pouvait donc être interfacée par RICERCAR.

Il a donc fallu procéder au " premier amorçage manuel " [Pitrat 90, chap. 10] :

  1. écrire une application Cold Fusion permettant de créer et détruire des objets de RICERCAR (il n'y avait alors pas de méthode new, seule l'invocation était possible) ;
  2. créer les premiers objets (formulaires) de cette application en les enregistrant " à la main " dans le dictionnaire (notamment la classe Document);
  3. utiliser les objets créés pour créer les classes suivantes ;
  4. décrire les nouvelles classes et leurs méthodes, représentant la nouvelle version de RICERCAR (optimisation du code tenant compte de l'amorçage), et les créer à l'aide de la version précédente ;
  5. utiliser les nouvelles méthodes de destruction implémentées pour éliminer les classes de la version transitoire, étendre et compléter les dictionnaires formant RICERCAR.

Au sortir de ces amorçages, RICERCAR référence tous les documents de tous les utilisateurs finals. C'est ainsi que l'utilisateur particulier qu'est RICERCAR a désormais accès à l'ensemble des procédures et modules qui le composent. Il a de même accès à toutes les (méta) informations nécessaires à son fonctionnement : l'ensemble des serveurs avec lesquels il peut interagir, ainsi que la localisation de l'ensemble des documents.

La réflexivité de RICERCAR garantit l'homogénéité entre les applications d'entreprise et le noyau du système qui utilisent les mêmes représentations.
La réflexivité de RICERCAR garantit l'homogénéité entre les applications d'entreprise et le noyau du système qui utilisent les mêmes représentations.

REALISATIONS ET PERSPECTIVES

Le fonctionnement et les performances actuels de RICERCAR, après plus d'un an d'expérimentation et d'amorçage [11] sont encourageants. De nombreuses fonctionnalités et applications d'entreprise ont été très rapidement intégrées (création d'objets particuliers), sans impact mesurable sur les performances globales, notamment :

  •  ANTILOPE (ANnuaires Téléphoniques Informatisés des Lieux, Organisations et Personnes de l'Entreprise) : application client-serveur sous ORACLE 7.2/HP-UX ;
  •  95 PPP (Offre médicale de la RATP) : application client-serveur sous ORACLE 7.2/SV-R4 ;
  • AMI (Abonnement aux Modifications en Intranet) : mise en relation des classes d'utilisateurs et des dictionnaire pour permettre la souscription d'un abonnement qui informe, par messagerie, de la modification d'une sélection de documents ;
  •  Revue de Presse [12]: mise à la disposition de l'entreprise en septembre 1997 d'une revue de presse quotidienne (remplacement progressif de la version imprimée - 1800 exemplaires, 25 pages en moyenne) ;
  • RIME (Recherche Intranet par Mots-clEfs) : intégration du moteur d'indexation et de recherche Search'97 [Verity 96]. L'application surcharge la méthode Exec de la classe Index et construit alors à partir des dictionnaires la liste des objets correspondants aux critères de recherche ;
  • NOURIR (NOUveautés sur le Réseau Intranet de la RATP) : surcharge aussi la méthode Exec de la classe Index pour générer la liste, ordonnée par date, des nouveautés d'une sélection de serveurs.

De nombreuses améliorations sont en cours de réalisation, notamment en terme d'ergonomie des méthodes d'administration et de publication ainsi que la complétion de statistiques plus élaborées.

Des modifications plus fondamentales sont par ailleurs à l'étude, dont les priorités de réalisation seront déterminées en fonction du retour des expérimentations effectuées :

  • détermination d'un modèle de réplication des données de RICERCAR afin de dupliquer les objets sur un ensemble de serveurs. Il s'agit d'assurer :
  1. la minimisation des trafics sur le réseau : servir à l'utilisateur le document demandé à partir du serveur topologiquement le plus proche (la distance étant à déterminer) ;
  2. une tolérance aux pannes et perturbations du réseau : pallier la défaillance d'un serveur en répartissant les accès qui lui sont destinés vers un ensemble d'autres serveurs.

Des problèmes complexes de synchronisation des données doivent cependant être résolus. Il faut notamment pouvoir déterminer quel exemplaire du document peut être mis à jour par l'utilisateur, quels mécanismes de réplication utiliser en cas de modification, quelles valuations pour calculer la distance minimale du couple (utilisateur, document demandé), etc.

  • faire évoluer le référentiel actuel vers un ensemble d'annuaires X.500 [CCITT X.500] ou LDAP [Yeong 95] afin d'utiliser les mécanismes intrinsèques de réplication des données ainsi que les différents protocoles de requêtes prévus entre DSA/Serveurs LDAP (qui répondent à une partie des problèmes énoncés au point précédent) ;
  • " Un programme d'Intelligence Artificielle qui a de bons résultats n'est pas intéressant... " [Pitrat 84].
  • Le développement incrémental [13] de RICERCAR s'est imposé dans le cadre d'une recherche essentiellement effectuée en entreprise où il n'est pas acceptable de proposer un système opérationnel - fût-il intéressant - dont les performances soient médiocres. Nous avons donc limité notre ambition à un système intéressant et ayant de bons résultats : ce n'est donc pas - encore - un programme d'Intelligence Artificielle. Ses amorçages ont cependant permis de construire RICERCAR comme un système multi-agents [Tisseau 96] auquel manque la réflexivité opératoire [Ferber 89]. Les serveurs sont eux-mêmes des objets distribués dont le dictionnaire remplit le rôle d'un tableau noir [Ermann 80] et dont l'index fédéré - lui-même un tableau noir - est le dispositif de contrôle [Hayes-Roth 85]. Les objets deviennent alors des agents qui peuvent communiquer en échangeant des messages asynchrones avec continuation [Briot 89] (les redirections d'URL paramétrées).

CONCLUSION

Il s'avère à l'usage que l'intranet pose un ensemble de problèmes qui ne relèvent pas tous, loin s'en faut, de la technique. S'il apporte une réelle solution au déploiement du client-serveur, sa transversalité justifie cependant de le considérer globalement, comme une " application " d'entreprise.

Il nous apparaît en effet nécessaire de garantir une qualité de service aux utilisateurs finals, qui suppose des informations diversifiées, fiables, rafraîchies et généralement accessibles, sans formation préalable. L'intranet qui n'est, somme toute, qu'une vue particulière de données de l'entreprise, doit en garantir la cohérence, à la grande différence de l'Internet, auquel il emprunte la technologie mais non l'organisation.

Il est donc important que l'ensemble des intervenants puissent enrichir le système de façon sûre (authentifiée), harmonieuse (respect d'une identité graphique) mais simple. Il est aussi important de pouvoir proposer de nouvelles fonctionnalités sans remise en cause de l'existant.

L'architecture que nous proposons répertorie, dans une hiérarchie de classes, différents modèles de documents correspondant à une charte graphique et des fonctionnalités données. La génération effective des pages HTML se fait par le biais de méthodes qui masquent à l'utilisateur la complexité et la régularité de ces modèles. L'intégration de données issues d'applications plus anciennes se ramène ainsi à l'écriture des requêtes spécifiques et à la mise en forme des résultats.

RICERCAR fait correspondre les URL aux identifiants des objets. Indépendantes de la localisation effective de ces objets, celles-ci peuvent alors être référencées par un lien hypertexte sans crainte d'une incohérence future dans la navigation. Cette décorrélation permet par ailleurs de mieux répartir les objets en fonction de leur usage sans en perturber l'accès.

Élaborée depuis près de deux ans, cette architecture volontairement implémentée à partir d'outils " du marché " en est toutefois totalement indépendante. Son évolution souhaitable vers un des grands standards que sont CORBA et DCOM ne devrait pas poser de difficultés techniques majeures mais doit pour autant être différée par manque de vision stratégique claire de l'entreprise (si un ORB est désormais inclus dans le navigateur de Netscape, Microsoft fait quant à lui le forcing pour imposer COM/DCOM sur l'ensemble des serveurs et des postes de travail de l'entreprise, souvent acquise à ses solutions).

BIBLIOGRAPHIE

[Adams 97]Adams S., " Le principe de Dilbert ", First Éditions, Lonrai, France, mars 1997.
[Alin 97]Alin F., Lafont D. et Macary J.-F., " Le projet intranet: de l'analyse des besoins de l'entreprise à la mise en œuvre des solutions " , Eyrolles, Paris, France, 1997.
[Allaire 96]Allaire J.J. , " Introducing COLD FUSION 3.0 ", Juillet 1997, <URL:http://www.allaire.com/products/coldfusion/30/>.
[Augendre 97]Augendre M., " Un enjeu pour les organisations ", Sciences Humaines, n°16, mars 1997, pp. 42-45.
[Berger 97]Berger P., " L'intranet, un chantier social ", 27 Juin 1997, Le Monde Informatique, n° 728, p.16.
[Berners-Lee 94a]Berners-Lee T., " Universal Resource Identifiers in WWW ", Juin 1994, Internet RFC-1630, <URL:http://www.internic.net/rfc/rfc1630.txt>.
[Berners-Lee 94b]Berners-Lee T., Masinter L. and McCahill M., " Universal Resource Locators (URL) ", Décembre 1994, Internet RFC-1738 , <URL:http://www.internic.net/rfc/rfc1738.txt>.
[Boehm 88]Boehm B., " A spiral Model of Software Development and Enhencement ", IEEE Computer 21 (5), May 1988, pp. 61-72.
[Bossard 97]Bossard Consultants, " Intranet et l'entreprise : Tout ce qui va vous empêcher de faire de l'INTRANET ", Mars 1997, Communication privée (97BG0373), Paris, France.
[Bouzeghoub 97]Bouzeghoub M., Gardarin G. et Valduriez P., " Les Objets : Édition revue et augmentée ", Eyrolles, Paris, France, 1997, (1ère Ed. 1994).
[Bitouzet 97]Bitouzet C., Fournier P., et Montcel B.T., " Management et intranet ", Hermès, Paris, France, Février 1997.
[Black 94]Black A. and Walpole J., " Objects to the rescue! or httpd: the next generation operating system ", Proceedings of the 6th ACM-SIGOPS European Workshop, Warden, Germany, September 1994.
[Briot 87]Briot J.-P. and Cointe P., " A Uniform Model for Object-Oriented Languages Using the Class Abstraction ", IJCAI'87, Milano, Italy, 1987.
[Briot 89]Briot J.-P., " Actalk : a Testbed for Classifying and Designing Actor Languages in the Smalltalk-80 Environment ", Proceedings of ECOOP'89, Notthingham, UK, 1989, pp. 109-129.
[Brown 96]Brown N. and Kindel C., " Distributed Component Object Model Protocol -- DCOM/1.0 ", November 1996 , draft-brown-dcom-v1-spec-01 (expiré) , <URL:http://www.internic.net/internet-drafts/draft-brown-dcom-v1-spec-01.txt > .
[CCITT X.500]CCITT, " Réseaux de communications de données : Annuaire ", novembre 1988, CCITT Recommandations X.500 à X.521.
[Coad 91] Coad P. and Yourdon E., " Object Oriented Analysis ", Prentice Hall, Englewood Cliffs, U.S.A, 1991.
[Colan 97]Colan M., " InfoBus Specification ", 21st August 1997, Draft Version 0.04A, <URL:http://java.sun.com/beans/infobus/ibspec.html >.
[Coulouris 95]Coulouris G., Dollimore J. and Kindberg T., " Distributed Systems : Concepts and Design. Second Edition ", Addison-Wesley, London, UK, 1995, (1st Ed. 1990).
[Dhénin 97]Dhénin C., " De l'approche statique à l'accès dynamique : Comment faire cohabiter Web et base de données ", Le Monde Informatique, n° 719, 25 avril 1997, pp. 22-23 .
[Dufour 96]Dufour A., " Internet ", coll. " Que sais-je ? ", PUF, Paris, France, février 1996.
[Ferber 89]Ferber J., " Objets et agents : une étude des structures de représentation et de communications en Intelligence Artificielle ", Thèse de Doctorat d'État, Université Paris 6, 8 juin 1989.
[Fielding 95]Fielding R., " Relative Uniform Resource Locators ", Juin 1995, Internet RFC-1808, <URL:http://www.internic.net/rfc/rfc1808.txt>.
[Franks 97]Franks J., Hallam-Baker P., Hostetler J., Leach P., Luotonen A., Sink E. and Stewart L., " An Extension to HTTP : Digest Access Authentication ", Janvier 1997, Internet RFC-2069, <URL:http://www.internic.net/rfc/rfc2069.txt>.
[Ermann 80 ]Ermann L.D., Hayes-Roth F., Lesser V.R. and Reddy D.R., " The Hearsay-II speach understanding system : Integrating knowlegde to resolve uncertainty ", Computing Surveys 12, 1980, pp. 213-253.
[Gardarin 90]Gardarin G. et Valduriez P., " SGBD Avancés : Bases de données objets, déductives, réparties ", Eyrolles, Paris, France, 1990.
[Hayes-Roth 85]Hayes-Roth F., " A Blackboard Architecture for Control ", Readings in Distributed Artificial Intelligence, A.H. Bond and L. Gasser (Editors), 1985, pp. 505-540.
[Hower 97]Hower R., " Beyond Broken Links " , DBMS, n° 8, Vol.10, Juillet 1997, pp. S9-S11.
[Kristol 97]Kristol D. and Montulli L., " HTTP State Management Mechanism ", février 1997, Internet RFC-2109, <URL:http://www.internic.net/rfc/rfc2109.txt>.
[Kunze 95]Kunze J., " Functionnal Recommendations for Internet Resource Locators ", Février 1995 , Internet RFC-1736 , < URL: http://www.internic.net/rfc/rfc1736.txt >.
[Lefebvre 97]Lefebvre A., " Intranet : client-serveur universel ", Eyrolles, Paris, France, 1997.
[Lie 96]Lie H.W. and Bos B., " Cascading Style Sheets, level 1 ", W3C Recommandation, 17 décembre 1996, <URL:http://www.w3.org/pub/WWW/TR/REC-CSS1>.
[McCool 94]McCool R., " The Common Gateway Interface ", 1994, <URL:http://hoohoo.ncsa.uiuc.edu/cgi/>.
[Microsoft 92]Microsoft, " Microsoft ODBC SDK Preliminary Release ", Microsoft, Redmond, U.S.A, March 1992.
[OMG 96a]Object Management Group, " The Common Object Request Broker: Architecture and Specification. Revision 2.0 ", OMG, Massachussetts, U.S.A, Juillet 1996, (1ère Ed. Juillet 1995).
[OMG 96b]Object Management Group, " CORBAservices ", OMG, Massachussetts, U.S.A, 1996 .
[Orfali 95]Orfali R., Harkey D., Edwards J., " Essential Distributed Objects Survival Guide ", John Wiley and Sons, New York, U.S.A, 1995.
[OSF 93]OSF, " OSF DCE Application Development Guide, Revision 1.0 ", Prentice Hall, Englewood Cliffs, U.S.A, 1993.
[Pitrat 84]Pitrat J., " Quelques Remarques sur "Intelligence artificielle, mythes et limites" ", In Dreyfus H.L., " Intelligence Artificielle, Mythes et Limites ", Flamarion, Paris, France, 1984.
[Pitrat 90]Pitrat J., " Métaconnaissance, Futur de l'Intelligence Artificielle ", Hermès, Paris, France, 1990.
[Rumbaugh 96]Rumbaugh J., Blaha M. Eddy F., Premerlani W. et Lorensen W., " OMT : Modélisation et conception orientées objet ", Masson, Paris, France, 1996, (1ère Ed. 1991, Prentice Hall).
[Sauteur 97]Sauteur B., " Intranet : le monde client-serveur enfin disponible ! ", 1er Septembre 1997, Informatiques Magazine, n° 33, p. 24.
[Séraphin 97]Séraphin J., " Réseau Intranet : Communication dans un Ensemble Réparti, Cohérent et Administré,
à la RATP ", Expo intranet, 30 mai 1997, <URL:http://ricercar.math-info.univ-paris5.fr/ricercar/Intranet_Expo_97>.
[Sollins 94]Sollins K. and Masinter L., " Functionnal Requirements for Uniform Resource Names ", Décembre 1994, Internet RFC-1737 , < URL:http://www.internic.net/rfc/rfc1737.txt >.
[Steiner 88]Steiner J., Neuman C. and Schiller J., " Kerberos: an authentication service for open network systems ", Proceedings of Usenix Winter Conferences, Berkeley, U.S.A, 1988.
[Tisseau 96]Tisseau G., " Intelligence Artificielle : Problèmes et méthodes ", PUF, Paris, France, avril 1996.
[Verity 96]Verity, " Search'97 ", 11 décembre 1996, <URL:http://www.verity.com/PR/961211p.html>.
[Yeong 95]Yeong W., Howes T. and Kille S., " Lightweight Directory Access Protocol ", mars 1995, Internet RFC-1777, <URL:http://www.internic.net/rfc/rfc1777.txt>.
[Young 90]Young A., " The X Window System, Programming and Applications with Xt ", Englewood Cliffs, U.S.A, Prentice Hall, 1990.

Notes

1. Il est entendu qu'" entreprise " représente ici, de façon générale, des entreprises disposant de plusieurs centaines de postes de travail. Nous avons en effet pu constater une assez grande homogénéité du traitement et de la perception de l'intranet en France, après deux années de contacts réguliers.

2. rfc1630, rfc1736, rfc1737, rfc1738 et rfc1808.

3. " Should " dans la rfc1630, incitatif mais non comminatoire.

4. Universal Resource Identifier

5. Basic Authentication Scheme.

6. Le code de l'ensemble des méthodes peut être consulté en <URL:http://ricercar.math-info.univ-paris5.fr/RICERCAR/ricercar_pgm>.

7. Common Gateway Interface.

8. Notamment une conception réflexive " à la LISP " matérialisée par une administration dynamique de l'interpréteur, elle-même écrite en CFML, une fonction evaluate qui permet de construire - et d'interpréter - non seulement du code HTML mais aussi du code CFML et la possibilité d'enrichir le langage en écrivant des procédures C++ ou, plus classiquement, en définissant de nouvelles fonctions à partir de combinaisons de fonctions existantes.

9. Il s'installe sur tout serveur Windows NT -95 supportant CGI, ISAPI , NSAPI ou WSAPI ainsi que sous UNIX (CGI).

10. CF 3.01 (7/97) invoque des classes DCOM et la V.4.0, annoncée pour janvier 98, prévoit d'intégrer un ORB écrit en Java (VisiBroker ?).

11. Le noyau du système est passé en plus d'un an - de la V.1 à la V.5.4 - par trois amorçages, effectués en une vingtaine de versions intermédiaires pour préserver les performances et fonctionnalités d'ensemble.

12. C'est la première application intranet officielle à la RATP (Cf. § 3).

13. Les différents éléments suivants sont cités pour justifier cette construction itérative. Ils feront l'objet de développements ultérieurs.

 

"notere97" a été publié par Jse RiceRcaR le 21/06/1999, (modifié le 14/07/2001 à 20h25mn).
Serveur administré par JSb RICERCAR