2. Mise en place du service

Pour la réalisation du service expérimental " CNDP ", nous avons fait le choix de nous faire héberger par un serveur installé, déjà configuré et connecté à l'Internet. L'ensemble des problèmes de connexion au réseau Internet, d'installation d'un serveur, d'installation et de configuration du Daemon Web, ne seront pas abordés ici. On se limitera à donner quelques informations générales sur ce point.

2.1. L'hébergement

Il faut noter que l'hébergement constituera dans bien des cas une solution simple pour être présent sur Internet, et mettre en place quelques services de base. Les opérations concédées de gestion technique sont simples et peu coûteuses, et la gestion des contenus peut être réalisée soit localement, soit au moyen d'une connexion à distance.

Les Daemon Web consomment en effet très peu de ressources et de mémoire ; dès lors qu'un site dispose d'une bande passante suffisante pour éviter les saturations du lien avec Internet, l'hébergement d'un service n'entraîne aucune charge de travail complémentaire pour le site hébergeur. Il appartient alors au gestionnaire du service de maintenir ses fichiers à jour, et le service concédé se limite alors à la gestion de l'espace disque (avec toutes les opérations liées, notamment la sauvegarde), à la fourniture d'une faible puissance de traitement CPU, et surtout à la connectivité avec Internet.

Cependant, si cette solution peut paraître tout à fait pertinente pour un service d'accès à quelques dizaines de pages HTML, il est tout à fait inadapté pour la gestion de services complexes, faisant appel à des programmes externes, et notamment à des bases de données et des bases documentaires. Il est en effet alors nécessaire d'avoir la maîtrise de la configuration de la machine, et on ne peut se contenter de l'accès à une portion d'arborescence.

Pour tenir compte de cette difficulté, de nombreuses sociétés proposent (aux États-Unis, il ne faut pas rêver) d'héberger sur leur réseau, connecté à Internet avec un débit suffisant, une machine appartenant à chacun de leurs clients désireux d'ouvrir un service Internet. Cette possibilité est sans doute également intéressante pour nous, puisqu'elle permet d'installer un serveur sur Internet, avec une large maîtrise de sa configuration.

Pour les utilisateurs, la localisation du service est indifférente, et un service hébergé sera identifié aussi bien que s'il était entièrement géré " à domicile ". Les coûts d'installation et de gestion d'un serveur, et de connexion à Internet, ne sont donc pas un préalable à la mise en place d'un service, et on pourra, dans bien des cas, les différer jusqu'au moment où la phase de mise en place et de montée en charge sera achevée.

2.2. Définition du projet

La méthode d'accès à l'information de Web impose une segmentation soignée des services, chacun des cheminements utilisateur devant être court. Comme dans le cas de la télématique traditionnelle, il est indispensable de produire un schéma d'organisation du service et de ses sous-services, avec une modélisation soignée des liens (bien plus complexes et nombreux que ceux d'un service Minitel).

Pour le serveur expérimental CNDP, nous avons décidé d'utiliser l'architecture définie dans le projet " un bouquet de téléservices pour l'éducation ", qui prévoit cinq sous-services (informations administratives, utilitaires et catalogage, ressources éducatives, ressources en ingénierie éducative, outils de communication). Pour les accès publics, un service d'entrée présentant le CNDP a été ajouté, mais un accès direct aux services (et même à un service spécifique) pourra être mis en place.

Structure de base des services.

La structure de Web se prête bien à une analyse de plus en plus fine des sous-services, chacun pouvant être conçu de manière indépendante dès lors que l'on a défini les chaînages principaux entre eux, et que le masque de page principal est déterminé.

On retrouve ici le problème traditionnel de la télématique : définir des procédés de cheminement à peu près standardisés que l'on retrouvera à toutes les étapes. En revanche, les commandes étant réalisées par des clics sur des textes ou des images qui peuvent être très explicites, il ne sera pas nécessaire d'apporter une attention aussi soutenue à la cohérence des actions liées aux commandes (on se souviendra des commandes standard du Minitel sommaire, retour, * retour, etc.).

2.3. Composition des pages

La composition des pages a été réalisée avec l'Internet Assistant pour Word distribué par Microsoft (version bêta) pour Word 6, dans une version imposant l'utilisation d'un Word américain (cette contrainte est à présent caduque). Bien que comportant de nombreuses limitations et même générant des erreurs de syntaxe HTML dans certains cas (IAW n'effectue aucune vérification de syntaxe), cet outil est extrêmement facile à mettre en œuvre, et permet de composer aisément ses premières pages.

Il est nécessaire d'apporter le plus grand soin à l'homogénéité de la présentation, l'outil n'assurant aucun contrôle à ce niveau.

D'une manière générale, la composition en visualisation directe offerte par Internet Assistant pour Word, bien que facilitant grandement le travail de composition, n'est pas suffisante, et il faudra par la suite éditer le texte source, notamment pour les fonctions avancées liées, par exemple, aux placements des images. Il est alors indispensable de disposer d'un guide de référence du langage, et de plusieurs clients, avec des configurations différentes, et si possible des types de machines différents (l'exécution sur Mac peut réserver quelques surprises...).

2.4. Les limites de la vérification en exécution locale

Bien qu'il soit possible d'exécuter le programme HTML (le terme de programme est quelque peu excessif) directement dans Word (avec Internet Assistant), la vérification apportée ne saurait dépasser un premier niveau dans le fonctionnement des chaînages.

Une exécution locale avec un autre client, comme Netscape ou Mosaic, permettra de vérifier de manière plus efficace le fonctionnement, notamment la mise en page et les placements des images. On notera d'ailleurs quelques différences entre les différents logiciels, dues à leur mode de fonctionnement, à leur présentation (taille de la zone écran disponible pour l'affichage, par exemple), mais aussi surtout à leur paramétrage. C'est en effet le client qui attribue à chaque style de paragraphe une police et un corps, et à chaque enrichissement standard (<STRONG> par exemple) un enrichissement typographique.

Toujours pour ce qui concerne la présentation, pour le service CNDP, le choix a été fait de privilégier une taille d'écran de 640 X 480, mais les clients peuvent utiliser d'autres définitions (800 X 600 par exemple) qui peuvent changer la mise en page. Des tests dans plusieurs configurations permettront d'apprécier l'incidence de ce choix.

On notera également que HTML utilise le jeu de caractère dit " ISO Latin-1 " qui prévoit la possibilité de coder l'ensemble des caractères diacritiques, en particulier les caractères accentués et autres trémas et tildes, sous forme de codes utilisant uniquement des caractères ASCII normalisés. Cette possibilité permet de s'affranchir des différents codages utilisés selon les machines et les pays pour les caractères étendus, et un document sera consultable dans son intégrité en tout point du monde, sur toute machine, qu'il ait été écrit en français ou en finnois (en fait, toutes les langues utilisant les caractères alphanumériques). Cependant, cette fonctionnalité doit explicitement être vérifiée : la version utilisée d'Internet Assistant pour Word, par exemple, réalise automatiquement cette conversion, mais malheureusement pas sur le texte des ancres hypertextes ! Le protocole HTTP fonctionnant sur 8 bits, les caractères étendus non codés selon HTML seront restitués correctement dès lors que l'on utilise les mêmes pages de code, en particulier sur des machines identiques. Mais sur des machines différentes (Mac et PC, par exemple...), on retrouve les erreurs d'interprétations des caractères étendus, et le codage HTML devient impératif. N'oublions pas que le monde entier pourra avoir accès à nos services !

Enfin, pour tout ce qui concerne les chaînages vers d'autres services au travers de leurs URL, il ne sera possible de les tester que dans la mesure ou le programme est implanté sur un serveur, et exploité par un logiciel Daemon Web.

2.5. Insérer des images

L'insertion d'images est prévue, dans le langage HTML, par des références à des fichiers graphiques externes. Les formats les plus utilisés sont le GIF, défini par Compuserve, particulièrement adapté pour les dessins, et le JPEG (extension .JPG), format normalisé, plus adapté à la restitution d'images. Il faut cependant noter que l'utilisation de GIF fait actuellement l'objet d'une contestation de la part de Compuserve, qui considère qu'il s'agit d'une violation des principes de la protection de la propriété intellectuelle. Il est possible que ce format doive être abandonné dans les mois à venir.

La plupart des clients Web reconnaissent nativement ces formats, soit directement par des fonctions du logiciel (Netscape), soit à l'aide d'une application externe (par exemple Lview, souvent utilisé comme visualiseur d'images dans Mosaic).

Il faut noter que ces clients, dans le cas d'images JPEG codées sur 24 bits (16 millions de couleurs), sont généralement capables d'adapter les données en fonction des capacités de l'adaptateur graphique, ce qui permet de s'affranchir totalement des problèmes de palette (en 256 couleurs). Ces fonctions, déjà assurées directement par le système sur les Macintosh, évitent d'avoir à dégrader les images pour en permettre la restitution sur tous les matériels, et garantissent la meilleure exploitation.

Le format GIF est largement utilisé sur Web, en particulier pour les types de documents que HTML ne sait pas traiter directement. On peut en particulier citer les formules mathématiques et les tableaux (éléments qui seront incorporés dans HTML 3.0), qui sont actuellement traités à l'aide d'une conversion GIF en mode image (le programme Late to HTML assure cette conversion). Pour améliorer la qualité de restitution, on utilise généralement des images GIF " transparentes ", qui utilisent le fond standard de la page comme couleur de fond.

L'insertion d'une image dans l'Internet Assistant pour Word se fait directement par la fonction Insert Picture, comme pour insérer une image dans un texte Word. On remarquera que cette fonction est active pour tous les types d'images reconnus par Word, ce qui ne veut pas dire que les clients sauront les exploiter ! On notera également que les fonctions avancées de positionnement des images et du texte par rapport aux images (images à droite, texte en haut, en bas ou au milieu, etc.) ne sont pas exploitables par Word, bien qu'il produise un code source généralement utilisable par les autres clients. Il sera nécessaire d'éditer le texte source pour modifier les paramètres de positionnement...

Exemple d'insertion d'image GIF dans un titre de niveau 1.

On peut également noter qu'il est parfaitement possible d'insérer dans le document HTML une image qui n'est pas présente localement, mais qui est accessible sur un autre serveur. Cette fonctionnalité peut être utile pour éviter de dupliquer des données disponibles, mais aussi pour permettre l'accès à des données dynamiques, par exemple une image satellite actualisée toutes les trois heures.

2.6. Organisation physique des ressources

Dès la composition des premières pages et des premiers chaînages, il est indispensable de définir une stratégie d'organisation physique des ressources dans l'arborescence du disque. Le référencement des ressources locales peut être fait par des chemins absolus ou relatifs, mais dans tous les cas l'organisation du disque est primordiale.

La syntaxe HTML permet de passer dans l'en-tête du fichier une adresse de base pour l'arborescence (<BASE>), à partir de laquelle seront définis tous les chemins relatifs. L'utilisation de cette fonction évitera des difficultés au moment de réaliser des chaînages entre des sous-services. Elle n'est cependant pas offerte directement par Internet Assistant pour Word.

Il faudra également vérifier directement dans le texte source toutes les références à des ressources locales (fichiers HTML, images, objets divers, etc.) établies automatiquement par Word, certaines étant des références fondées sur des chemins relatifs, d'autres absolus, d'autres encore faisant référence à des chemins comportant des unités logiques du réseau qui ne sont valides que pour la session de travail en cours.

D'une manière générale, la composition ne se faisant pas sur le disque et la machine qui supporteront le service, il est préférable d'utiliser des chemins relatifs, soit paramétrés à partir d'une base commune référencée dans l'en-tête (<BASE>), soit à partir du répertoire local du fichier HTML initial. Le remplacement par des adresses absolues peut également constituer un moyen d'éviter les erreurs.

Les choix d'organisation physique conditionnent directement la réalisation des chaînages. Il faut donc apporter un soin tout particulier à ce point, car il sera extrêmement difficile de le modifier ultérieurement.

L'utilisation de chemins relatifs permettra éventuellement de changer l'organisation du serveur, en déplaçant l'ensemble de l'arborescence du service, simplement en changeant la base du Daemon Web.

2.7. Installation sur un serveur

Une fois les pages composées et le service mis au point en local, il faut le transférer sur le serveur. Bien entendu, cela suppose que le Daemon a été installé et configuré au préalable, et l'opération, très simple sur un système Macintosh (MacHTTP) ou Windows NT (HTTP Server), peut être plus complexe sur un système UNIX : la génération de l'application à partir d'un script peut être entièrement automatique, mais il n'est pas rare que des erreurs se produisent (chemins, droits, fonctions pas tout à fait compatibles de certains UNIX, etc.), et il est alors nécessaire de modifier les scripts à la main. Une bonne connaissance du système est alors nécessaire.

Il faut noter que les logiciels les plus récents sont toujours fournis sous la forme d'exécutables, et qu'ils sont aisément paramétrables au moyen de fichiers de configuration en texte ASCII abondamment documentés. Cela permet notamment d'avoir des logiciels pratiquement identiques sous les différents systèmes, en particulier pour le paramétrage. Ainsi, la version Windows du serveur NCSA (httpd) est architecturée de la même manière que le serveur UNIX, et se paramètre pratiquement de la même manière.

Le Daemon exploite des fichiers à partir d'un chemin de base, qui constitue en fait une racine virtuelle (Daemon Web root) à partir de laquelle les fichiers devront être organisés. Dans le cas où on gère plusieurs services, il peut être utile de faire tourner plusieurs sessions du serveur, gérant des bases différentes. Généralement, la procédure d'installation prévoit de donner tous les droits nécessaires à l'exploitation des fichiers par le logiciel serveur, et installe un utilisateur chargé de la gestion du service. Comme pour les autres systèmes de réseau, il est prudent de définir un nom d'utilisateur par personne physique pour la gestion de chacun des sous-services.

Si on souhaite utiliser des fonctions de téléchargement, il est nécessaire d'utiliser un serveur FTP, et, dans la plupart des cas, de déclarer un utilisateur " anonymous ". Les fichiers correspondants devront être placés dans une arborescence spécifique, dotée des droits correspondants. Dans la mesure où les utilisateurs peuvent avoir accès aux catalogues, il est préférable de placer les ressources FTP dans une branche différente de l'arborescence. Il sera également utile de leur donner une organisation soignée, et de prévoir des fichiers " lisez.moi " pour faciliter l'accès à partir d'un simple client FTP.

Exemple d'organisation des ressources sur un serveur.

De nombreux serveurs sont organisés en un serveur FTP anonyme, dont les ressources sont organisées dans une arborescence spécifique, et un serveur Web qui permet également l'accès à ses ressources. Dans de nombreux cas, on trouve également un serveur Gopher permettant d'accéder aux mêmes données...

Pour le service expérimental CNDP, le serveur étant une station Next utilisant un système proche d'UNIX, il est nécessaire d'utiliser les fonctions FTP pour l'opération d'installation des fichiers. Dans le cas de systèmes utilisant la notion d'unités logiques (serveurs de réseau local Windows NT ou Netware, systèmes NFS), l'opération pourra être réalisée plus simplement, par simple copie, et les modifications pourront être effectuées en ligne.

La station Next utilisée étant configurée pour associer au Daemon Web aux fichiers ayant pour suffixe " .HTML ", il a été nécessaire de renommer tous les fichiers au cours de l'opération de transfert, ainsi que de modifier en conséquence toutes les références entre les fichiers locaux, si cela n'a pas été fait au préalable avec Word. Il est bien évident qu'il aurait été plus simple de reconfigurer la station pour accepter les fichiers d'extention .HTM, mais cela aurait nécessité une modification des paramétrages du serveur, toujours délicate pour une machine qui abrite plusieurs services. On touche ici aux difficultés de l'hébergement sur une machine dont on n'a pas la maîtrise, et pour laquelle toute modification de paramétrage nécessite une intervention du superviseur.

Il est ensuite indispensable de vérifier le bon fonctionnement de tous les chaînages, à partir d'une station connectée sur le réseau TCP/IP. En cas d'incident, le fichier incriminé devra être édité et modifié en conséquence. Pour cela, il faudra soit disposer d'une copie accessible sur la station cliente, qui sera ensuite transférée sur le serveur (en changeant son nom), soit le modifier directement sur le serveur, en utilisant un éditeur de texte.

Il pourra également être utile de vérifier le fonctionnement en liaison téléphonique, notamment pour vérifier que les temps de transfert des pages ne sont pas insupportables. Nombre de services magnifiques en liaison haut débit se révèlent inutilisables à 14 400 bits par seconde.

Bien que tous les points précédents puissent paraître lourds aux non-initiés, la mise en place du service est très aisée. Il reste, bien sûr, quelques difficultés mineures, mais on est surpris de voir un service élaboré sur un système fonctionner aussi facilement sur un autre, aussi différent. Quant à la complexité, elle reste sans commune mesure avec celle que nous avons pu connaître sur les autres systèmes téléinformatiques, et en particulier le Minitel.

Sommaire

Suite